RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds
Alan Bateman
alanb at openjdk.java.net
Fri Oct 22 10:20:05 UTC 2021
On Fri, 22 Oct 2021 09:33:35 GMT, Jaikiran Pai <jpai at openjdk.org> 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
More information about the core-libs-dev
mailing list