ImmutableMap.copyOf(Iterable<Map.Entry<K, V>>)

[GoogleCodeExporter]

I often want to create a Map from its entrySet.  I've rolled my own version
of this in a few of my projects.  It would be nice to have a standard API
for it.

Original issue reported on code.google.com by fin...@gmail.com on 30 Jan 2010 at 9:49

[GoogleCodeExporter]

The interface proposed in Issue #330 would also solve this.

Original comment by fin...@gmail.com on 8 Dec 2010 at 12:07

[GoogleCodeExporter]

Why not simply use ImmutableMap.copyOf(Map)?

Original comment by fry@google.com on 28 Jan 2011 at 3:58

[GoogleCodeExporter]

Original comment by fry@google.com on 28 Jan 2011 at 4:02

• Added labels: Type-Enhancement

[GoogleCodeExporter]

I think the answer to that question is "because what have is a Set<Entry>, not 
a Map."  I am not clear on why exactly users find themselves in this situation, 
but plan to look deeper into it.

Original comment by kevin...@gmail.com on 28 Jan 2011 at 9:00

• Changed state: Accepted

[GoogleCodeExporter]

I regularly start with Iterable<E> and end up with Iterable<Map.Entry<K,V>> 
where sometimes E=K or E=V, it's much simpler to keep working with 
Iterable<Map.Entry<K,V>> and only in the end instantiate a Map<K,V>.

Original comment by daniel.y...@gmail.com on 28 Jan 2011 at 10:55

[GoogleCodeExporter]

It strikes me that while an Iterable<Map.Entry<K,V>> does not always represent 
the entrySet() of a Map, it could be the entrySet() of a Multimap.  Perhaps we 
should look at it in that way instead?

Original comment by wasserman.louis on 8 Mar 2011 at 8:26

[GoogleCodeExporter]

That is probably the best case anyone's made yet for the value of methods 
accepting Iterable<Map.Entry>!  I am smacking myself for never thinking of it 
this way -- how many times I've lamented that Map and Multimap implement no 
common interface!

If someone would look through the whole API for any examples of methods that 
would really want to accept either Map or Multimap (meaning that they can 
plausibly deal with duplicate keys), then we can look at the feasibility of 
It<Entry>-accepting versions of those methods.

Original comment by kevinb@google.com on 9 Mar 2011 at 3:07

[GoogleCodeExporter]

I'm not sure I follow.

I haven't yet found any methods that "would really want to accept either Map or 
Multimap," but here's the point I was initially trying to make:

If we're presented with an Iterable<Map.Entry<K,V>>, we don't have any 
guarantee that the keys are distinct.  (Map.entrySet() returns a 
Set<Entry<K,V>> for precisely the reason that we're certainly guaranteed that 
there are no duplicate entries.)  However, any Iterable<Map.Entry<K,V>> could 
be the entries() of a Multimap, regardless of duplication.

In particular, I'd certainly support a 
LinkedListMultimap.create(Iterable<Entry<K,V>>), with the result that the 
entries() of the resulting multimap would be the same entries in the same order.

Another, related, possibility would be Multimap.putAll(Iterable<Entry<K,V>>), 
since there is currently no putAll(Map<K,V>).

Original comment by wasserman.louis on 9 Mar 2011 at 5:53

[GoogleCodeExporter]

I'd like to see the addition of methods to create a map from 
`Iterable<Map.Entry<K, V>>` -- preferably both mutable and immutable.

I'm not sure about the MultiMap-related discussion here; currently I'm just 
concerned about basic maps.

Original comment by j...@nwsnet.de on 31 Mar 2011 at 12:03

[GoogleCodeExporter]

MapJoiner is an example of something I'd like to see support Multimap as well 
as Map... I wanted to be able to do this for some code I was playing with 
recently. I wrote up the code for that and was going to submit a separate 
issue, but was reminded of this.

Original comment by cgdec...@gmail.com on 14 Apr 2011 at 3:54

[GoogleCodeExporter]

Just realized that supporting Multimap directly in MapJoiner would break the 
package-dependency rule I seem to recall seeing mentioned at some point, but 
Iterable<Map.Entry<?, ?>> wouldn't.

Original comment by cgdec...@gmail.com on 14 Apr 2011 at 4:01

[GoogleCodeExporter]

Original comment by kevinb@google.com on 13 Jul 2011 at 6:18

• Changed state: Triaged

[GoogleCodeExporter]

Original comment by fry@google.com on 10 Dec 2011 at 3:43

• Added labels: Package-Collect

[GoogleCodeExporter]

Issue 861 has been merged into this issue.

Original comment by wasserman.louis on 11 Jan 2012 at 5:13

[GoogleCodeExporter]

Original comment by fry@google.com on 16 Feb 2012 at 7:17

• Changed state: Acknowledged

[GoogleCodeExporter]

...I observe that creating maps from iterables of entries is listed in the Idea 
Graveyard.  (I'm working on justifying it, though...?)

Original comment by wasserman.louis on 17 Feb 2012 at 7:08

[GoogleCodeExporter]

@wasserman.louis, see also kevinb's comment on Issue 385

Original comment by fin...@gmail.com on 17 Feb 2012 at 7:13

[GoogleCodeExporter]

Ah.  I did not see that.

Original comment by wasserman.louis on 17 Feb 2012 at 7:17

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 May 2012 at 7:43

• Added labels: Type-Addition
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by kevinb@google.com on 22 Jun 2012 at 6:16

• Changed state: Research

[GoogleCodeExporter]

Issue 1107 has been merged into this issue.

Original comment by wasserman.louis on 14 Aug 2012 at 7:18

[GoogleCodeExporter]

Issue 1107 has been merged into this issue.

Original comment by wasserman.louis on 14 Aug 2012 at 7:19

[GoogleCodeExporter]

Issue 1107 has been merged into this issue.

Original comment by lu...@google.com on 14 Aug 2012 at 7:23

[GoogleCodeExporter]

Kevin, to contribute to your research effort, here's the reason I currently 
need this: Someone implemented something as a List<Pair> that really should 
have been a Map. I'm writing some temporary translation code for backwards 
compatibility. (Yes, it's temporary, but I'd still like it to be concise and 
readable.)

Original comment by jaredjac...@gmail.com on 5 Oct 2012 at 11:39

[GoogleCodeExporter]

Issue 1116 has been merged into this issue.

Original comment by kak@google.com on 23 Oct 2012 at 4:45

[GoogleCodeExporter]

Also consider varargs Entries, consider Builder.

Original comment by kevinb@google.com on 23 Oct 2012 at 4:45

[GoogleCodeExporter]

I highly support this.

Also for Multimaps please :

1. static ImmutableMultimap.copyOf(Iterable<Map.Entry<K, V>>)
2. (instance) Multimap.putAll(Iterable<Map.Entry<K, V>>)
3. I would love to have instance-level Map.putAll(Iterable<Map.Entry<K, V>>) 
but since
   it's part of JDK then this would do:

   static Maps.putAll(Map<K, V>, Iterable<Map.Entry<K, V>>)

I also request similar addition but for Multiset, please vote issue #1189 too 
:-)

Original comment by ceefour666@gmail.com on 3 Nov 2012 at 3:45

[GoogleCodeExporter]

http://stackoverflow.com/questions/13527055/how-to-create-a-treemultimap-from-an
-iterable-collection/13532402#13532402 seems like a genuinely valid use case 
for the Multimap variant.  Tldr:  Iterables.limit on an Iterable of entries is 
a reasonable need, though I'd imagine that applies only when the entries have 
some predictable order.  The Map variant would usually be something like 
Ordering.least of for sorted maps?

Original comment by lowas...@google.com on 23 Nov 2012 at 4:05

[GoogleCodeExporter]

Also, in gson, the JsonObject has an entrySet() method - but it would be nice 
to directly convert that into a Map (instead of littering iteration code 
everywhere).

Original comment by adomma...@axian.com on 26 Jun 2014 at 12:07

[GoogleCodeExporter]

We were convinced internally that there was a need for this; it's been added, 
and the change will be mirrored out soon.

Original comment by lowas...@google.com on 26 Sep 2014 at 9:43

• Changed state: Fixed

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:16

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:10

• Added labels: Restrict-AddIssueComment-Commit