On Thu, 4 Nov 2021 03:18:40 GMT, Jaikiran Pai <jai.forums2...@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
