Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jlink error Hash of java.rmi differs to expected hash #280

Closed
janst44 opened this issue Jul 27, 2022 · 6 comments
Closed

jlink error Hash of java.rmi differs to expected hash #280

janst44 opened this issue Jul 27, 2022 · 6 comments
Labels
bug Something isn't working

Comments

@janst44
Copy link

janst44 commented Jul 27, 2022

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.

@janst44 janst44 added the bug Something isn't working label Jul 27, 2022
@lutkerd
Copy link
Contributor

lutkerd commented Jul 28, 2022

Thank you for reporting this, we have reproduced the issue and are working on a fix.

@Rudometov
Copy link
Contributor

This issue has been fixed in 11.0.16.8.3.

@tresf
Copy link

tresf commented Aug 4, 2022

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.

@mikehearn
Copy link

@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.

@tresf
Copy link

tresf commented Aug 14, 2022

@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.

@mikehearn
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants