search

okaywit / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

Make Multimap putAll/replaceAll more clear about empty collection behavior #1458

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
e.g:
    HashMultimap<Integer, Long> idBlackListMap = HashMultimap.create();

if i post the param like this , the key losted :
    idBlackListMap.putAll(1, ImmutableSortedSet.of())

the putAll implementation  is : 
    return values.iterator().hasNext() && Iterables.addAll(get(key), values);

this is a little strange 。 u can reject the emptyList , but never ignore the 
key

Original issue reported on code.google.com by magician...@gmail.com on 27 Jun 2013 at 6:44

GoogleCodeExporter commented 9 years ago 
Why is this strange?  The Multimap spec implies that the key should be ignored 
here.

Original comment by wasserman.louis on 27 Jun 2013 at 3:43

GoogleCodeExporter commented 9 years ago 
fall into the pitfall.

puted it , but it isn't in the keyset.

Original comment by magician...@gmail.com on 28 Jun 2013 at 8:41

GoogleCodeExporter commented 9 years ago 
Perhaps this could be documented better? The class Javadocs mention several 
places that a Multimap containing no values mapped to a key does not contain 
that key, but maybe it would help to add a note/warning on putAll given that it 
does allow you to attempt to add no values. replaceValues could possibly use a 
similar note.

Original comment by cgdec...@gmail.com on 28 Jun 2013 at 4:23

GoogleCodeExporter commented 9 years ago

Original comment by kevinb@google.com on 29 Jun 2013 at 1:38

GoogleCodeExporter commented 9 years ago

Original comment by kevinb@google.com on 3 Jul 2013 at 1:16

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Jul 2013 at 2:41

GoogleCodeExporter commented 9 years ago 
This issue has been migrated to GitHub.

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

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

GoogleCodeExporter commented 9 years ago

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