RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v14]

[Severin Gehwolf]

> 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 b
 eing 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.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Add some details for run-time link
   
   Also clean up the --verbose output.
 - Always add the runtime image stamp file
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Rename '--unlock-run-image' to '--ignore-modified-runtime'
 - Remove --unlock-run-image from jlink.properties
 - Fix IntegrationTest (no runtime image link)
 - The constants such as the pathname of the timestamp file and the internal file listing
   per-module non-class non-resource files are part of jlink.  Move the constants to
   JlinkTask to follow where OPTIONS_RESOURCE is defined.
   
   JRTArchive scans the class and resource files of a given module from the runtime image.
   It should also read `fs_$MODULE_files` to find the list of non-class and non-resource files.
   
   The current implementation checks if a file is modified lazily when Entry::stream
   is called and so it has to remember if file modification has been checked and
   warning has been emitted.   I think doing the file modification check eagerly
   when collectFiles is called would simplify the code.
   
   For maintainability, better to move the reading of and writing to `fs_$MODULE_files`
   together in a single class rather than separated in JRTArchive and JlinkResourcesListPlugin.
 - Disallow packaged modules and run-time image link
 - Only check for existing path when not a scratch task
   
   When using a run-time image link and the initial build was produced with
   the --keep-packaged-modules option, we don't need to check existing
   paths to the location where packaged modules need to be copied. This
   breaks the --verbose output validation.
 - Add @enablePreview for JImageValidator that uses classfile API
 - ... and 45 more: https://git.openjdk.org/jdk/compare/c9cacfb2...9635ba52

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=13
  Stats: 3211 lines in 39 files changed: 3041 ins; 132 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787