On Tue, 5 Dec 2023 19:15:53 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >> install might not come with the packaged modules (directory `jmods`). This >> is particularly useful to further reduce the size of a jlinked runtime. >> After the removal of the concept of a JRE, a common distribution mechanism >> is still the full JDK with all modules and packaged modules. However, >> packaged modules can incur an additional size tax. For example in a >> container scenario it could be useful to have a base JDK container including >> all modules, but without also delivering the packaged modules. This comes at >> a size advantage of `~25%`. Such a base JDK container could then be used to >> `jlink` application specific runtimes, further reducing the size of the >> application runtime image (App + JDK runtime; as a single image *or* >> separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking >> non-class and non-resource files of a JDK install. I.e. files which aren't >> present in the jimage (`lib/modules`). This enables producing a `JRTArchive` >> class which has all the info of what constitutes the final jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmod java.net.http.jmod java.sql.rowset.jmod >> jdk.crypto.ec.jmod jdk.internal.opt.jmod >> jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod >> jdk.dynalink.jmod jdk.internal.vm.ci.jmod >> jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod >> java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod >> jdk.editpad.jmod jdk.internal.vm.compiler.jmod >> jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod >> jdk.hotspot.agent.jmod jdk.i... > > Severin Gehwolf has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 46 commits: > > - Add @enablePreview for JImageValidator that uses classfile API > - Fix SystemModulesPlugin after merge > - Merge branch 'master' into jdk-8311302-jmodless-link > - Don't show the verbose hint when already verbose > - Use '_files' over '_resources' as the suffix for listing resources > - Remove the hidden option hint. > > Also adjust the messages being printed when performing > a run-time image link. > - Localize messages, switch expression > - Rename RunImageArchive => JRTArchive and RunImageLinkException => > RuntimeImageLinkException > > Also moved the stamp file to jdk.jlink module. The resources files per > module now get unconditionally created (empty if no resources not in the > jimage). > - First round of addressing review feedback. > > - Share resource names (JlinkTask and JlinkResourcesListPlugin) > - Exclude resources in JlinkResourcesListPlugin the same way > as done for other plugins. > - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin > - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69 I tried out the latest commit (a797ea69). The output "The default module path, '$java.home/jmods' not present. Use --verbose to show the full list of plugin options applied" is bit confusing as it looks like jlink failed but it actually succeeded. Blowing away the generated image and retrying with --verbose tripped this assert java.lang.AssertionError: handling of scratch options failed at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302) at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183) at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177) at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672) ... 5 more I haven't dug into this yet but I'm puzzled that the file path to where the original build was created is in the exception messages, is that recorded? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1847408088
