Generating jre from sdk on Macos gives error.

[prajwal-s-nayak]

Generating jre using jlink gives error on Macos. The modules provided for --add-modules are the ones which are listed in --list-modules option. On windows and linux it works fine.

Sdk used: http://w3.hursley.ibm.com/java/jim/ibmsdks/java11/110120/macosxx8664/index.html

version: 11.0.12

GOLO12854:macOS-JRE persistent$ ../jdk-11.0.12+7/Contents/Home/bin/jlink --output ./generate_jre11_macOS --add-modules java.base,java.compiler,java.datatransfer,java.desktop,java.instrument,java.logging,java.management,java.management.rmi,java.naming,java.net.http,java.prefs,java.rmi,java.scripting,java.se,java.security.jgss,java.security.sasl,java.smartcardio,java.sql,java.sql.rowset,java.transaction.xa,java.xml,java.xml.crypto,jdk.accessibility,jdk.attach,jdk.charsets,jdk.compiler,jdk.crypto.cryptoki,jdk.crypto.ec,jdk.dynalink,jdk.editpad,jdk.httpserver,jdk.internal.ed,jdk.internal.jvmstat,jdk.internal.le,jdk.internal.opt,jdk.jartool,jdk.javadoc,jdk.jcmd,jdk.jconsole,jdk.jdeps,jdk.jdi,jdk.jdwp.agent,jdk.jlink,jdk.jshell,jdk.jsobject,jdk.localedata,jdk.management,jdk.management.agent,jdk.naming.dns,jdk.naming.ldap,jdk.naming.rmi,jdk.net,jdk.pack,jdk.rmic,jdk.scripting.nashorn,jdk.scripting.nashorn.shell,jdk.sctp,jdk.security.auth,jdk.security.jgss,jdk.unsupported,jdk.unsupported.desktop,jdk.xml.dom,jdk.zipfs,openj9.cuda,openj9.dataaccess,openj9.dtfj,openj9.dtfjview,openj9.gpu,openj9.jvm,openj9.sharedclasses,openj9.traceformat,openj9.zosconditionhandling 
Error: Hash of java.rmi (bfbf4653051033eb3ed1e828bce58f617e609c0c7c6c8cb86d2743df0584c378) differs to expected hash (077dce096028d2862846b94a0b91c2dceaa504b056a6f3b0bc6cb04ce7295c33) recorded in java.base

Found a similar issue : AdoptOpenJDK/openjdk12-binaries#1

[AdamBrousseau]

@narkedi is this the same issue you already are aware of or is this something new?

[narkedi]

@AdamBrousseau That's true, its the same issue which is due to the mismatch in SHA's.

[mbarbero]

The error exists in 11.0.12 and 11.0.13 (latest as of today).

I cannot reproduce with 11.0.11.

[pshipton]

It still occurs with the latest (11.0.16)

[keithc-ca]

If signing occurs after the jmod is produced, it will affect the hash, so this should not be surprising. Has anyone checked builds from adoptium to see if they have the same symptoms?

[pshipton]

Has anyone checked builds from adoptium to see if they have the same symptoms?

I believe I did and the Adoptium build worked. I think there is another issue about this somewhere where I documented that.

[AdamBrousseau]

There's several issues at Adoptium but this one adoptium/temurin-build#1214 seem to be a good starting point. They've fixed the issue.

[aahlenst]

I was sent here by @tresf. I barely remember any details and it also wasn't me who implemented it at AdoptOpenJDK. If I remember correctly, the key is to make an exploded image, sign it, and then to reassemble it. Basically, you run the build twice with different arguments and skip the configure step on the second pass.

https://github.com/adoptium/ci-jenkins-pipelines/blob/83d8718155a85eb2dc5cdf0005bce62c7ace0ae2/pipelines/build/common/openjdk_build_pipeline.groovy#L1375-L1461 and https://github.com/adoptium/temurin-build/blob/3d0981f31c10ca3e6e533703bb7e6e168609e32c/sbin/build.sh#L574-L577 look like the most relevant parts.

[koppor]

Also happens in the build available today. Minimal example repository: https://github.com/koppor/openj9-hash-issue

[koppor]

Current output

Error: Hash of java.rmi (03f539ebf91c81cfc7a81236d2c1109e0d050c839d03c6f757022b99a10cb819) differs to expected hash (07126a5cefcc6c19d9059cfa4b42ec832f3714a1ef89f103afc2d1ab61b79bc7) recorded in java.base