On Fri, 22 Oct 2021 09:33:35 GMT, Jaikiran Pai <j...@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. This pull request has now been integrated. Changeset: 396132ff Author: Jaikiran Pai <j...@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/396132ff1e56463ad195cac5c9ac8e2eac5a16e8 Stats: 92 lines in 2 files changed: 88 ins; 0 del; 4 mod 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Reviewed-by: alanb, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/6078
