On Wed, 6 Oct 2021 08:33:21 GMT, Peter Levart <plev...@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
