On 08/05/2017 00:06, Remi Forax wrote:

Hi all,
I wonder if it's an issue or if there is a rational for not suppressing this 
error when using --ignore-signing-information.

I'm patching the compiler related modules of the jdk9 with the one from 
amber/langtools, so i know that i'm doing something borderline but i gently ask 
jlink to do not bother me with the hash signature.

...
jlink --module-path ./target/main/artifact:./deps:/usr/jdk/jdk-9-b167/jmods
       --add-modules 
jdk.policytool,jdk.charsets,jdk.pack,jdk.xml.dom,java.xml,jdk.deploy,java.datatransfer,java.jnlp,java.desktop,com.github.forax.pro.uberbooter,java.se,jdk.snmp,java.security.sasl,jdk.deploy.controlpanel,jdk.zipfs,java.base,jdk.crypto.ec,com.github.forax.pro.main,jdk.management.agent,jdk.jshell,jdk.editpad,oracle.desktop,jdk.jsobject,jdk.unsupported,java.smartcardio,jdk.scripting.nashorn,java.security.jgss,com.github.forax.pro.plugin.convention,jdk.dynalink,java.activation,java.sql,java.logging,jdk.jfr,jdk.internal.vm.ci,com.github.forax.pro.plugin.packager,jdk.packager.services,jdk.net,javafx.controls,jdk.internal.ed,jdk.compiler,jdk.naming.rmi,jdk.jconsole,jdk.internal.le,jdk.packager,jdk.jdwp.agent,jdk.internal.vm.compiler,com.github.forax.pro.daemon.imp,java.scripting,jdk.jartool,java.rmi,jdk.jdi,jdk.javaws,jdk.rmic,com.github.forax.pro.plugin.resolver,jdk.jstatd,jdk.httpserver,java.se.ee,jdk.jcmd,javafx.base,com.github.forax.pro.plugin.linker,com.github.forax.pro.plugin.compiler,jdk.plugin.dom,com.github.forax.pro.plugin.modulefixer,jdk.javadoc,jdk.xml.ws,java.sql.rowset,jdk.sctp,javafx.swing,jdk.jlink,jdk.scripting.nashorn.shell,oracle.net,java.xml.bind,java.compiler,javafx.graphics,javafx.fxml,jdk.plugin,javafx.media,jdk.accessibility,jdk.security.jgss,javafx.web,com.github.forax.pro.plugin.uberpackager,jdk.hotspot.agent,javafx.deploy,java.xml.crypto,jdk.incubator.httpclient,jdk.plugin.server,jdk.crypto.cryptoki,java.naming,java.prefs,jdk.internal.opt,jdk.attach,java.transaction,java.xml.ws,java.xml.ws.annotation,java.management,jdk.xml.bind,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,jdk.jdeps,jdk.aot,java.corba,java.management.rmi,jdk.naming.dns,jdk.localedata
       --launcher pro=com.github.forax.pro.main/com.github.forax.pro.main.Main
       --compress 0
       --ignore-signing-information
       --output ./target/image
Error: Hash of jdk.javadoc 
(5b3a628bce2aad807392ea8a3f2ce69a652e885e33db586694b47fcf6f5ebf52) differs to 
expected hash 
(6bdf7f26f72c9f102c5052f8ddf68a80a4b18f997a16e56805e3acc7347469b5) recorded in 
java.base

`--ignore-signing-information` is used when linking signed modular JARs into a run-time image and is nothing to do with the integrity hashes that are used to avoid mixing tied modules from different builds.

If you've patched jdk.compiler, jdk.javadoc, and other modules in your jdk9/dev or jigsaw/jake build then I wouldn't expect any issues. I'm guessing therefore that you've patched the packaged modules or less re-created a subset of the JMOD files. When you do that then the hashes stored in java.base will not match. If you re-create java.base.jmod then it will generate the hashes to match the updated modules. Alternatively for your local testing you could just drop the ModuleHashes class file attribute.

-Alan



Reply via email to