jlink SystemModulesPlugin use of hashCode breaks reproducibility

[Craig Raw]

Hi,

While I've noticed significant improvements in making reproducible builds
with JDK 16, there is a remaining issue I'm stumped by. The issue is this:

Using jlink invokes the SystemModulesPlugin, which creates .class files
containing module descriptors for all the modules of the application.
Specifically, these .class files are SystemModules$all.class and
SystemModules$default.class. The class files create instances of
jdk.internal.module.Builder to create the ModuleDescriptor objects. The
ModuleDescriptors are created by use of the Builder.build(int hashCode)
method. The problem is this: the value of the hashCode parameter can change
when building across different systems, changing the bytecode of the
SystemModules$*.class files, and therefore the modules file created by
jlink.

It is unclear to me why the hashCode should differ. The SystemModulesPlugin
invokes ModuleDescriptor.hashCode() on line 1116, and that method should be
deterministic. However, I do note that the value is cached inside
ModuleDescriptor, and in fact a ModuleDescriptor can be constructed with a
provided hashCode value. Perhaps an outdated value is cached? My other
consideration is that integer overflow is behaving differently on some
systems, but I am targeting 64 bit systems only, and this issue is
occurring across similar Debian-based platforms running identical JDK
versions (adoptopenjdk-16-hotspot=16.0.1+9).

The issue is illustrated with an example here:
https://github.com/sparrowwallet/sparrow/issues/197

Note that this issue is intermittent - many users are able to create
reproducible builds of this project, but some are not. For reference, the
steps to creating a reproducible build are documented here (note only the
1.5.0-beta1 release is reproducible):
https://github.com/sparrowwallet/sparrow/blob/master/docs/reproducible.md

Any assistance in resolving this is appreciated.

Regards,
Craig