Using 13 versus 31 seems irrelevant, I agree. I think the important
difference might be that Object.hash() starts the hashcode with a
constant value of "1". Some of our hashCode implementation also do
something similar -- see Point2D for example. I haven't looked at it
closely enough to see if that matters, but it might. Btw, here is the
definition for List.hashCode which I think is what Objects.hash ends up
doing:
int hashCode = 1;
for (E e : list) hashCode = 31*hashCode + (e==null ? 0 : e.hashCode());
-- Kevin
Jim Graham wrote:
All this does is change the prime constant used to produce the hash
value.
Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 13*hash(a)
+ hash(b) that the embedded implementation uses.
I don't really think this is a bug. The fact that Integer objects
make it easy to reverse engineer and compute collisions of any
reasonable hash combination computation don't mean that the technique
has a bug, it just means that the submitter can read the code and
think of a counter-example.
If there are practical problems being caused for some particular and
popular use case by the use of this particular constant "13", then we
need to understand those issues and come up with a more comprehensive
solution than to simply hand off to another mechanism which uses the
same procedure with a different prime constant...
...jim
On 11/3/15 3:06 AM, Vadim Pakhnushev wrote:
Hi Chien,
Could you please review the fix:
https://bugs.openjdk.java.net/browse/JDK-8140503
http://cr.openjdk.java.net/~vadim/8140503/webrev.00/
Thanks,
Vadim
