On 03/11/21 8:50 am, Jaikiran Pai wrote:
Hello Alan,

On 02/11/21 5:30 pm, Alan Bateman wrote:
On 02/11/2021 06:38, Jaikiran Pai wrote:
:

Perhaps run 1 writing the hash code of each of the boot modules' descriptor into a file and then run 2 reading that same file to compare the hash codes would be one way to do it. But I think that would just make this test more complex, which I think is avoidable.

I'm not sure that we really need this. There are several jlink tests that check reproducibility, we think one of them is failing intermittently with this issue already. So maybe we should leave build reproducibility to the jlink tests and expand them as needed.

For ModuleDescriptor::hashCode then I was hoping we keep it simple and just test that the hashCode of the descriptors for modules in the boot layer matches the hashCode computed from re-parsing the module-info files, e.g. something simple like this:

      for (Module module : ModuleLayer.boot().modules()) {
            System.out.println(module);
            ModuleDescriptor descriptor1 = module.getDescriptor();
            ModuleDescriptor descriptor2;
            try (InputStream in = module.getResourceAsStream("module-info.class")) {
                descriptor2 = ModuleDescriptor.read(in);
            }
            assertEquals(descriptor1, descriptor2);
            assertEquals(descriptor1.hashCode(), descriptor2.hashCode());
            assertEquals(descriptor1.compareTo(descriptor2), 0);
        }

It run can twice, with with the default, the other with -Xshare:off.

Sounds reasonable. I've updated the PR to simplify the test and run it once with default CDS and once with -Xshare:off. Given this simplification, it now allows me to use testng for these comparisons, so I've moved it from regular "main" to testng test case. I hope that's OK.

Test continues to pass with these changes and fails (as expected) when the fix in the source code of ModuleDescriptor class is rolled back.

-Jaikiran

Reply via email to