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

[Kevin Rushforth]

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