JDK-8243666 : ModuleHashes attribute generated for JMOD and JAR files depends on timestamps
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.module
  • Affected Version: 15
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-04-27
  • Updated: 2025-01-20
  • Resolved: 2020-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15
11.0.16Fixed 15 b21Fixed
Related Reports
CSR :  
JDK-8347349 - ModuleHashes attribute generated for JMOD and JAR files depends on timestamps
Duplicate :  
JDK-8241606 - Adding ModulePackages attribute leads to non-reproducible builds
Relates :  
JDK-8345881 - Interoperability issue when jlink and jmod module path uses different JDK
Relates :  
JDK-8241602 - jlink does not produce reproducible jimage files
Description
One of the reasons that JDK builds are not reproducible is that the hashes generated for modules packaged as JMOD files are computed from the entire file content, including timestamps and other meta data for entries in the JMOD. This should be re-examined as a hash based on the names and content of each entry should be sufficient.
Comments
[~clanger] We didn't identify the compatibility issue in JDK 15. If we had then we would have introduced a new algorithm value so that JDK 15+ would have support the original and new. So going forward, any changes to how the hash is computed or validated will need to take compatibility into account. The second issue that impacts JDK 11u only is jlink cross linking. We will need to tighten up the version checking to restrict this feature to feature to same vendor + same update, essentially same git hash. I've created JDK-8347831 to track this work.
20-01-2025
[~alanb], would it be possible to modify the code in 11u to avoid the behavior change while still having the builds reproducible? OTOH, since the behavior change has been backported so long ago, I guess it would not be a good idea to change it back again.
18-01-2025
I see this has been back ported to JDK 11u. One thing to note that this changes the hash computation to include the names of resources, and the ordering that they are hashed, previously the hash was computed solely from the contents in read order. This will be observable if someone attempts to run jlink with a module path containing modules that were computed with the older scheme. This behavior change should probably have been tracked by a CSR + RN. If I had spotted it in time, then I would have suggested this not be back ported or the back port be modified to avoid the behavior change.
12-12-2024
Fix request (11u) I'm requesting this backport because it resolves a potential issue with jlink when using it with debian packages that are built with debuild. We got a report here for SapMachine: https://github.com/SAP/SapMachine/issues/1009. debuild seems to modify the jmod files in a way that the hash computation as of JDK11 will yield different results (e.g. timestamps of files differ). The modified hash calculation solves this. It's a clean backport, I only had to resolved one copyright header diff. No regressions spotted in GHA and SAP's test system.
19-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/916 Date: 2022-03-18 09:12:01 +0000
18-03-2022
URL: https://hg.openjdk.java.net/jdk/jdk/rev/14592d2b2795 User: alanb Date: 2020-04-29 07:39:57 +0000
29-04-2020