Well, not exactly... Previously it was 13*hash(a) + hash(b) and now it's
31*(31 + hash(a)) + hash(b).
And apparently it improves the quality somehow. I did a test with 100^4
combinations and collision probability dropped by the factor of 3 from
0.065% to 0.022%.
Not really impressive, but still, and it uses well-defined utility method.
Yeah, I know it's not really a bug since you don't want to rely on the
hashCode at all...
Thanks,
Vadim
On 03.11.2015 22:35, 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
