On Wed, 6 Oct 2021 09:26:06 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). > > Yes, the reverted change to BitSet.hashCode in > https://github.com/openjdk/jdk/pull/4309 has the same property. It could be > applied without any visible effect. @plevart should I then file a follow-up ticket for `BitSet`? And should we change the JavaDoc providing there we have computation formula explicitly specified? ------------- PR: https://git.openjdk.java.net/jdk/pull/5811
