jlink error Hash of java.rmi differs to expected hash
janst44 opened this issue · 6 comments
Broken again on jdk11.0.16_8, See: #144 , #96
Error: Hash of java.rmi (655e73613aab2ec53fe9595bfc9d583b5294b726fda0d28637fbbfd405bf2cca) differs to expected hash (cc19ed73c0b16c94f8cae8db977a58a03345e18aa999cb312644d9d4b0236348) recorded in java.base
Here's the command: $JAVA_HOME/bin/jlink --no-header-files --no-man-pages --module-path jdk11.0.16_8/jmods --add-modules java.base,java.compiler,java.management.rmi,java.net.http,java.prefs,java.scripting,java.security.jgss,java.security.sasl,java.sql.rowset,jdk.httpserver,jdk.jfr,jdk.jsobject,jdk.unsupported,jdk.unsupported.desktop,jdk.xml.dom --output jre
In this case i'm targeting a windowsx86 and windowsx64 jdk from mac (both have the error).
If you fix it again could you supply both? We still support some old windows users.
Thank you for reporting this, we have reproduced the issue and are working on a fix.
This issue has been fixed in 11.0.16.8.3.
Hi, do you mind sharing the cause and fix for this issue? I would like to share it with another OpenJDK flavor experiencing the same issue with the same version.
@tresf It's because they rebuild the JMODs to do code-signing of the artifacts inside. The "real fix" is to change the build system to do this before the JMODs are created.
@mikehearn thanks kindly for the reply. From my understanding, openjdk has made a decision which will break jlink between major JDK11 releases as explained here: adoptium/adoptium-support#557 (comment). Assuming this is true, it appears there is no fix, it's a breaking change without intention of reverting.
In my case, I was able to ask the build system to do a version check against the running JVM versus the target JVM (for example, a user may be using the latest JDK11 from apt, homebrew, etc) but if this version is 11.0.16 or higher, take special action. In my case, that action was to download the target JVM (e.g. 11.0.13) and call jlink from within that version.
For projects that are already handling this workflow for newer JDKs, it's a matter of treating 11.0.16+ as if it's not the same MAJOR version, since a similar issue would occur if attempting to use using JDK17's jlink against JDK11, but it appears there's really no fix unless I'm misunderstanding something.
Thank you for the correction. Indeed, the comment I saw elsewhere about code signing was apparently a red herring. So, when jlinking 11.0.16+, you must use 11.0.16+, otherwise use 11.0.15 or less. A pain but I can adapt my own product to handle that.