-
Notifications
You must be signed in to change notification settings - Fork 21
MapWrapper.hashCode breaks expected contract of java.util.Map #10663
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think this may be all that is needed -- I think it's actually correct to call I need to add a regression test and see if this breaks any existing tests, I haven't finished getting a local scala build up and running on my laptop yet. Does this project have travis CI or anything like that? |
yes, when you submit a PR, our Jenkins instance will build it and run the tests. it's fine to submit a half-baked PR just for that purpose, just please clearly label it as such |
Great, thanks! I'll do that. |
This has been merged in both scala/scala#6233 and scala/collection-strawman#487 |
thanks for your patience in seeing this through |
MapWrapper
's hashCode does not behave the same as otherjava.util.Map
s, which can cause issues when trying to check equality of two collections where one collection is (or contains) aMapWrapper
and the other is or contains a regularjava.util.Map
Some background info:
java.util.Map
has the following contract for its hashCode:MapWrapper inherits its implementation of
hashCode
fromjava.util.AbstractMap
and so its implementation is correct. However, as defined, the hash code produced is the sum of theMap.Entry
objects' hashes, so this is also very much dependent on thehashCode
implementation of theMap.Entry
objects as well. This is the part thatMapWrapper
is doing incorrectly / differently from the java stdlib.The docs for
Map.Entry.hashCode
state:This ensures that e1.equals(e2) implies that e1.hashCode()==e2.hashCode() for any two Entries e1 and e2, as required by the general contract of Object.hashCode.
A quick check of some of the
Entry
implementations in the java stdlib confirms that this is how they are implemented.However, in MapWrapper, we have:
The important part being:
The end result can also be confirmed with a repl session like this:
I will try to open a PR to fix this, but wanted to open this issue first.
Thanks!
Alex
The text was updated successfully, but these errors were encountered: