RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds

[Jaikiran Pai]

On Thu, 4 Nov 2021 03:18:40 GMT, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

> > So I decided to stick with using the ordinal modifiers in the hashCode() computation. However, I'm not an expert on the performance aspects of the Collections and how much using the modifiers for hashCode() will improve the performance in this case. Perhaps that's what you meant by it not giving a good (enough) spread? If so, do let me know and I'll go ahead and update the PR to remove using the modifiers in the hashCode() computation and also update the javadoc of each of those hashCode() methods which state that the modifiers are used in the hashCode() computation.
> 
> Okay, but we may have to re-visit this some time because summing the ordinals won't give a good spread, e.g. STATIC+SYNTHETIC will give the same value as TRANSITIVE. This is why I was saying it would be nearly the same to just leave them out.

That's a good point and thank you for explaining that part. So to address that, how about not leaving them out, but instead of using `Enum#ordinal()` for the hashCode generation, we use `Enum#name()` which would translate to a `String#hashCode()`. Something like:


private static int modsHashCode(Iterable<? extends Enum<?>> enums) {
        int h = 0;
        for (Enum<?> e : enums) {
            h = h * 43 + Objects.hashCode(e.name());
        }
        return h;
    }

That way the hashCode isn't dependent on the Object identity (which is what the original issue was), is still reproducible across JVM runs and at the same tie should provide a good spread for examples like the one you noted. Furthermore, unlike the usage of `ordinal` where any reordering of the enum values would have changed the hashCode value (which was OK), this usage of `name()` doesn't exhibit that nature (which again should be OK).

I've updated the PR to use this construct. The test continues to pass. Let me know if this looks fine or if you prefer doing it differently.

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

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