[9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions

[Vadim Pakhnushev]

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