RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
Alan Bateman
alanb at openjdk.org
Wed Aug 10 15:34:42 UTC 2022
On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041?
>
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
>
> A new test has been added which reproduces the issue and verifies the fix.
test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 71:
> 69: */
> 70: @Test
> 71: public void testModifiersOrdering() throws Exception {
Are you planning to expand the test to cover Requires.Modifier and Exports.Modifier too?
test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 76:
> 74: // important to use Set.of() (i.e. backed by immutable set) to reproduce the issue
> 75: final Set<ModuleDescriptor.Opens.Modifier> mod1 = Set.of(
> 76: ModuleDescriptor.Opens.Modifier.SYNTHETIC, ModuleDescriptor.Opens.Modifier.MANDATED);
These should probably be "mods1" and "mods2" rather than "mod1" and "mod2" as they are a set of modifiers rather than a single modifier.
-------------
PR: https://git.openjdk.org/jdk/pull/9790
More information about the core-libs-dev
mailing list