The 'modules' image (jimage) packaged JDK resources

[Alan Bateman]

On 31/01/2024 01:41, Jiangli Zhou wrote:
> As part of the discussions of bringing 
> https://github.com/openjdk/leyden/tree/hermetic-java-runtime 
> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/tree/hermetic-java-runtime__;!!ACWV5N9M2RV99hQ!P1kaSBJTsyP-QDfpIa0aSJZkqSkjwowiqRo3Vvj3PVuVLfZAWE7wL8wChhhSWM7nzXUDk1x_p8jC0Yv6gqFZcQ8$> 
> related work into OpenJDK mainline under the leyden project, some of 
> us (cc'ed on the email) have started brainstorming (in several zoom 
> meetings) the idea of placing JDK resources in the modules image 
> (jimage). The resources would include conf/*, lib/<resources>, etc in 
> a regular JDK binary. In the hermetic-java-runtime prototype, the JDK 
> resources are packaged into an executable JAR image as normal JAR 
> entries. At runtime, accessing these resources goes through a JavaHome 
> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/hermetic-java-runtime/src/java.base/share/classes/jdk/internal/misc/JavaHome.java__;!!ACWV5N9M2RV99hQ!P1kaSBJTsyP-QDfpIa0aSJZkqSkjwowiqRo3Vvj3PVuVLfZAWE7wL8wChhhSWM7nzXUDk1x_p8jC0Yv6KzOBrxA$> class 
> using a ZipFileSystem. If JDK resources are part of the modules, the 
> static/hermetic image packaging and runtime accessing becomes further 
> cleaner.
>
> I recently prototyped that idea with a jlink plugin and some quick 
> runtime changes to access using Module.getResourceAsStream 
> <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Module.html#getResourceAsStream(java.lang.String)> (not 
> in the hermetic-java-runtime branch yet). The quick prototype 
> indicates it is feasible from an implementation point of view.

You can also try Class.getResourceAsStream as it will locate the "data" 
relative to the class that owns it. You'll find several examples in the 
JDK that do this already, e.g. legacy sun.net.www.MimeTable uses it to 
locate a properties file with default mappings.


> Following are a few points that have been discussed among us for more 
> broad discussions:
>
> - This probably will involve specification changes in order to place 
> the JDK resources into the modulesimage. Particularly, the 
> conf/*resource files were intended to be user configurable (pointed 
> out by Alan). Alan has been looking into those parts.

There are a dozen or so APIs that specify support for user-editable 
configuration in the run-time image. Some of these APIs already specify 
ways to override or augment with configuration that comes from somewhere 
else, some APIs do not. So some adjustments will be required to all of 
these APIs and it's an opportunity to get bring some consistency across 
the JDK at the same time.

The other bucket is data/other files in the lib tree. These won't 
require specification changes but they do have some implications, e.g. 
TZ data, replacing cacerts with a sym link, and a few others that have 
to be worked through.


>
> - Where should the resources be placed within the modulesimage? For 
> example, if conf/security/java.security is written (using the new 
> jlink plugin) into the image as /java.base/java.security, runtime can 
> just access "java.security" resource using the "java.base" module (via 
> getResourceAsStream()). Alternatively, if the file is written as 
> /java.base/conf/security/java.security, the conf/securitypackage needs 
> to be added for the java.basemodule.
>
For the user-editable configuration then the answer will be "nowhere" in 
most cases. The reason is that user editable in the run-time image is 
optional, as is the value for specific keys, so there are already 
defaults. So it might be that when jlink creates a static image that it 
just drops the resources in the "conf" section of each module.  
java.security will need special attention of course, it's a bit of an 
outlier right now.

The non-editable configuration needs thinking through as there are a 
number of options. As you point out, if the file is moved to be a 
resource in a "new package" then the module's set of packages will need 
to be expanded at packaging or link time. It's usually nice when the 
structure of the "output tree" matches the original "input tree" so if 
they are in the lib tree in the packaged module, the lib tree in the 
modular run-time image, then having them move to be resources in the 
"internal" lib tree in the static image might be the least surprising.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240131/5c25d1ac/attachment.htm>