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

[Peter Levart]

On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis <github.com+7693005+JarvisCraft 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).

Sorry, I was mislead by the comment above that because the original hashCode function is different, the hashCode will be different too. But I think this is not the case here. Original function is this:

        long hilo = mostSigBits ^ leastSigBits;
        return ((int)(hilo >> 32)) ^ (int) hilo;
        
new function (with inlined Long.hashCode(long)) looks like this:

        long hilo = mostSigBits ^ leastSigBits;
        return (int)(hilo ^ hilo >>> 32);

The difference is two-fold:
1. original function uses arithmetic shift right (division by 2^32 preserving the sign) while new function uses logical shift right (shifting in zeros from the left to the right)
2. original function casts individual arguments to int before doing XOR between them while new function XORs long arguments and applies cast to int at the end.

But those two differences do not affect the lower 32 bits of any of the intermediate results and therefore the end result is the same (unless I missed something). So I think no release notes is needed for this change. 

I think that https://github.com/openjdk/jdk/pull/4309 also dealt with similar change which was then reverted as a consequence (I'll have to check to be sure).

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

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