On Fri, 22 Oct 2021 09:33:35 GMT, Jaikiran Pai <[email protected]> wrote:
> Can I please get a review for this change which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various > components to compute the final hash code. While doing so it ends up calling > hashCode() on (collection of) various `enum` types. Since the hashCode() of > enum types is generated from a call to `java.lang.Object.hashCode()`, their > value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As > Alan notes in the mailing list discussion, any changes to the ordinal of the > enum (either due to addition of new value, removal of a value or just > reordering existing values, all of which I think will be rare in these > specific enum types) isn't expected to produce the same hash code across > those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart > from calls to the enum types hashCode(), rest of the calls in that > implementation, either directly or indirectly end up as calls on > `java.lang.String.hashCode()` and as such aren't expected to cause > non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2559: > 2557: continue; > 2558: } > 2559: h += e.ordinal(); This e == null check suggests there is an issue elsewhere, can you explain the scenario where you see this? Also can you drop the spurious use of "final" here, it's inconsistent with the existing code. Do you want us to look at the test? It looks like it needs clean-up and I'm not sure if you want to wait for the CDS issue or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078
