git: openjdk/leyden: hermetic-java-runtime: This is a newer solution for supporting the hermetic JDK resource files. The current change is a prototype that places java.security as /java.base/java/security/java.security in hermetic modules image. The new approach is based on input from discussions with Alan Bateman, Ron Pressler, Liam Miller-Cushon, Chuck Rasbold, Severin Gehwolf and Magnus Ihse Bursie.

[duke]

Changeset: b82d06c3
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-02-06 17:29:25 +0000
URL:       https://git.openjdk.org/leyden/commit/b82d06c358b924bd627d07e0cd0932f5d2e7be00

This is a newer solution for supporting the hermetic JDK resource files. The current change is a prototype that places java.security as /java.base/java/security/java.security in hermetic modules image. The new approach is based on input from discussions with Alan Bateman, Ron Pressler, Liam Miller-Cushon, Chuck Rasbold, Severin Gehwolf and Magnus Ihse Bursie.

HermeticResourcesPlugin is an optionally enabled jlink plugin that writes specified JDK resources into the hermetic modules. In the current version, it also writes the JDK resources in the original location in the runtime image as before. E.g. when the plugin is enabled with following option:

  --hermetic-resources /java.base/conf/security/java.security=/java.base/java/security/java.security

It finds the ResourcePoolEntry.Type.CONFIG entry that matches with the resource path (path string specified before “=”) specified in the option, then creates a new ResourcePoolEntry.Type.CLASS_OR_RESOURCE entry with the converted hermetic path (hermetic path string specified after “=”) in the modules image. Multiple “,” separated resources can be specified in the option, e.g.:

  --hermetic-resources <resource_path_1>=<hermetic_resource_path_1>,<resource_path_2>=<hermetic_resource_path_2>,...

The hermetic java.security is loaded with Security.class.getResourceAsStream() at runtime. See related discussion in https://mail.openjdk.org/pipermail/leyden-dev/2024-January/000507.html thread.

Motivations of the new approach:

- Cleaner hermetic image support for both packaging and runtime access. When JDK resources are included in the modules image. It helps decouple hermetic Java packaging work from `singlejar` for a more general solution.

- Testing has uncovered a few startup sequence issues with JAR entry based hermetic JDK resources using ZipFileSystem for accessing. Supporting hermetic JDK resources in the JDK modules image avoids using the ZipFileSystem during system bootstrapping and hence avoids the startup sequence issues.

! make/Images.gmk
! make/autoconf/spec.gmk.in
! make/autoconf/static-java.m4
! src/java.base/share/classes/java/security/Security.java
+ src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/HermeticResourcesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
! src/jdk.jlink/share/classes/module-info.java