RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode()

[Alan Bateman]

On Wed, 6 Oct 2021 08:33:21 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code.
>> 
>> Because `Long#hashCode(long)` uses other hashing function than the one currently used here:
>> 
>> https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442
>> 
>> the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified.
>> 
>> ---
>> 
>> Note: the comment to the bug states:
>> 
>>> Moved to JDK for further discussions of the proposed enhancement.
>> 
>> But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML).
>
> You do know that this might break things? If there are multiple versions of JDK present in some distributed system where participants do not agree on the hash code of an UUID value, it can behave erratically. For example using UUID as a key in a distributed cache like Infinispan is known to be troublesome if the hashCode of some key is not the same across the cluster. Usually there will not be a problem since all nodes in a cluster would use the same JDK version, but what about a rolling upgrade then? It would not be possible. I think at least this change needs to be documented in release notes.

@plevart may have a point and since this patch doesn't really have any benefits then maybe this PR/issue can be closed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5811