hashCode issue in Multimap javadoc

[GoogleCodeExporter]

The attached test creates a multimap in a few steps. The result is equal to 
itself but the hashCode function returns a different value the second time it 
is used.

Original issue reported on code.google.com by cyrille....@gmail.com on 11 Apr 2014 at 3:55

Attachments:

• Report1.java

[GoogleCodeExporter]

Is there a particular reason this test does not use generics?

Original comment by wasserman.louis on 11 Apr 2014 at 3:58

[GoogleCodeExporter]

FWIW: the root issue is that Collection does not define a hashCode contract, so 
the Collection returned by Collections2.transform uses the identity hash code, 
which is regenerated each time the transformed Multimap's asMap method is 
called.

The most acceptable solution I can see -- if we see this as an issue at all -- 
would be to make Collections2.transform use a well-defined function for its 
hashCode, rather than System.identityHashCode.

Original comment by wasserman.louis on 11 Apr 2014 at 4:03

[GoogleCodeExporter]

How about caching the identifyHashCode when it is used for the first time?
I think having a reliable hashCode avoids subtle surprises later on...

Original comment by cyrille....@gmail.com on 11 Apr 2014 at 4:30

[GoogleCodeExporter]

We'd have to cache the entire asMap; we couldn't just cache one element, and 
that would defeat the point of the view.

Original comment by wasserman.louis on 11 Apr 2014 at 4:31

[GoogleCodeExporter]

Yes, I see that this would only solve the problem in a few cases. I'm not sure 
how this should be best resolved. A non-constant hashCode is problematic, 
though.

Original comment by cyrille....@gmail.com on 11 Apr 2014 at 4:37

[GoogleCodeExporter]

This is an unfortunate effect of the fact that transformEntries() returns a 
plain Multimap unless you give it a ListMultimap.

Plain Multimaps are just as horrible around equals/hashCode as plain 
Collections are, for the same reason. As Multimap says, "*Warning:* instances 
of type Multimap may not implement Object.equals(java.lang.Object) in the way 
you expect (multimaps containing the same key-value pairs, even in the same 
order, may or may not be equal). The recommended subinterfaces provide a much 
stronger guarantee."

I suppose we should extend that to cover hashCode() as well?

Original comment by kevinb@google.com on 11 Apr 2014 at 4:40

[GoogleCodeExporter]

Yes, adding such a remark would be helpful.

Original comment by cyrille....@gmail.com on 11 Apr 2014 at 4:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Do I understand correctly that the issue is : when using multimap <keytype, 
valuetype> one needs to implement equals and hashcode for keytype (in most 
cases)? If so, I'll post a request for findbug to add some rule for that?

Original comment by Bogdan.A...@gmail.com on 25 Jun 2014 at 7:34

[GoogleCodeExporter]

You do need to do that for all value types; that's a universal truth. But 
that's not what's going on here. 

Oh and, this javadoc note was added, so this is resolved.

Original comment by kevinb@google.com on 25 Jun 2014 at 1:45

• Changed title: hashCode issue in Multimap javadoc
• Changed state: Fixed
• Added labels: Package-Collect, Type-ApiDocs

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 5 Aug 2014 at 10:30

• Added labels: Milestone-Release18

[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:09

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

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

• Added labels: Restrict-AddIssueComment-Commit