openjdk-systemtest JLINK test failures with jdk-11.0.4+11.3

[lumpfish]

Platform:

MacOS

Architecture:

x64

The openjdk-systemtest JLINK tests have started failing with messages like:

09:25:34  STF 01:25:34.054 - Monitoring processes: JLNK
09:25:35  JLNK stderr Resources tree, invalid data structure, skipping /java.base/
09:25:35  JLNK stderr Resources tree, invalid data structure, skipping /java.base/META-INF/services/
09:25:35  JLNK stderr Resources tree, invalid data structure, skipping /java.base/META-INF/services/java.nio.file.spi.FileSystemProvider
09:25:35  JLNK stderr Resources tree, invalid data structure, skipping /java.base/META-INF/services/java.nio.file.spi.FileSystemProvider
09:25:35  JLNK stderr Resources tree, invalid data structure, skipping /java.base/apple/security/
09:25:35  JLNK stderr Resources tree, invalid data structure, skipping /java.base/apple/security/AppleProvider$1.class
09:25:35  JLNK stderr Resources tree, invalid data structure, skipping /java.base/apple/security/AppleProvider$1.class

This started with the packaging changes introduced in jdk-11.0.3+11.3 to address notarization requirements and enabling the loading of unsigned dylibs.

Tests are now failing on all nightly builds - e.g. https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.system_x86-64_mac/29/console

[karianna]

Probably related to code signing...

[sxa]

Notarization / signing so tagging #1130 to link them together

[sxa]

@lumpfish Can you verify whether the latest JDK11 nightly builds do not have this problem?

[adamfarley]

Could this be connected?

01:17:18  Error: Hash of jdk.jartool (18a5f51e945686154a30d739c30067e3017f1b1dc8cdb7f27eefbe9af905798b) differs to expected hash (d6b9614f26b1a823b42af7ec40980545a3b59b71b2134b79b8f5dd5bb0eeda8e) recorded in java.base
01:17:18  java.lang.module.FindException: Hash of jdk.jartool (18a5f51e945686154a30d739c30067e3017f1b1dc8cdb7f27eefbe9af905798b) differs to expected hash (d6b9614f26b1a823b42af7ec40980545a3b59b71b2134b79b8f5dd5bb0eeda8e) recorded in java.base
01:17:18  	at java.base/java.lang.module.Resolver.findFail(Resolver.java:877)
01:17:18  	at java.base/java.lang.module.Resolver.checkHashes(Resolver.java:461)
01:17:18  	at java.base/java.lang.module.Resolver.finish(Resolver.java:360)
01:17:18  	at java.base/java.lang.module.Configuration.<init>(Configuration.java:141)
01:17:18  	at java.base/java.lang.module.Configuration.resolve(Configuration.java:424)
01:17:18  	at java.base/java.lang.module.Configuration.resolve(Configuration.java:256)
01:17:18  	at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:220)
01:17:18  	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:486)
01:17:18  	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:396)
01:17:18  	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:272)
01:17:18  	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
01:17:18  	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)

[tmancill]

Debian #944738 looks very similar but is reported against the Debian build of OpenJDK. I wonder if they have a common root cause. The bug reported there is also with jlink;

   jlink --module-path build/jmods:$JAVA_HOME/jmods \
         --strip-debug --vm=server --compress 2 --no-header-files --no-man-pages \
         --dedup-legal-notices=error-if-not-same-content --add-modules http.server \
         --output build/jre/native

   Error: Hash of jdk.httpserver (3072fe4924fdf278791460cc0f0f7cc7e693e6eca4b3564b5252792750c3bd25)
   differs to expected hash (f7140e5db2cb90e7f8f6bcf30ef0660e1496b29dd1a20f07b3c4fcc18de5d787)
   recorded in java.base

[bartduisters]

I experience a similar issue while using jpackage on Ubuntu 20.04.1 LTS.
I have tried both with AdoptOpenJDK 14 and the default OpenJDK 14.

jpackage -n TestFX -i target --main-jar testFX-1.0-SNAPSHOT-jar-with-dependencies.jar -d output --module-path /home/barry/SDKS/javafx-sdk-14.0.2.1/lib
WARNING: Using incubator modules: jdk.incubator.jpackage

java.lang.module.FindException: Hash of jdk.management.jfr (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) differs to expected hash (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) recorded in java.base

[sblantipodi]

same exact problem of @bartduisters here.
is there a workaround for the problem?

[aahlenst]

The original issue was about macOS and it was caused by code signing. This was fixed, so I close this issue. jpackage and Ubuntu are unrelated.

@sblantipodi and others: If your problem isn't build related, please open an issue in https://github.com/AdoptOpenJDK/openjdk-support/issues and provide as much information as possible. The information you provided is not sufficient to diagnose the problem.

[bartduisters]

@sblantipodi You can follow the issue for our problem here: adoptium/adoptium-support#168

[tresf]

The original issue was about macOS and it was caused by code signing. This was fixed, so I close this issue. jpackage and Ubuntu are unrelated.

@sblantipodi and others: If your problem isn't build related, please open an issue in https://github.com/AdoptOpenJDK/openjdk-support/issues and provide as much information as possible. The information you provided is not sufficient to diagnose the problem.

@aahlenst do you mind sharing your solution with ibmruntimes/Semeru-Runtimes#3?