<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 31/01/2024 01:41, Jiangli Zhou wrote:<br>
<blockquote type="cite" cite="mid:CALrW1jwSvmMFGp_2_SxJkhMyunp8cz6MrAkHU4wt0CNK0k46-g@mail.gmail.com">
<div dir="ltr">As part of the discussions of bringing <a href="https://urldefense.com/v3/__https://github.com/openjdk/leyden/tree/hermetic-java-runtime__;!!ACWV5N9M2RV99hQ!P1kaSBJTsyP-QDfpIa0aSJZkqSkjwowiqRo3Vvj3PVuVLfZAWE7wL8wChhhSWM7nzXUDk1x_p8jC0Yv6gqFZcQ8$" moz-do-not-send="true">https://github.com/openjdk/leyden/tree/hermetic-java-runtime</a>
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 <font face="monospace">modules</font> image (jimage). The resources
would include<font face="monospace"> conf/*</font>, <font face="monospace">lib/<resources></font>, 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 <a href="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$" moz-do-not-send="true">JavaHome</a> class using a
ZipFileSystem. If JDK resources are part of the <font face="monospace">modules</font>, the static/hermetic image
packaging and runtime accessing becomes further cleaner.
<div><br>
</div>
<div>I recently prototyped that idea with a <span class="" id=":7pu.1" tabindex="-1" role="menuitem" aria-haspopup="true" style="">jlink</span> plugin and some
quick runtime changes to access using <a href="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Module.html#getResourceAsStream(java.lang.String)" moz-do-not-send="true">Module.getResourceAsStream</a> (not
in the hermetic-java-runtime branch yet). The quick prototype
indicates it is feasible from an implementation point of
view. </div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite" cite="mid:CALrW1jwSvmMFGp_2_SxJkhMyunp8cz6MrAkHU4wt0CNK0k46-g@mail.gmail.com">
<div dir="ltr">
<div>Following are a few points that have been discussed among
us for more broad discussions:</div>
<div><br>
</div>
<div><font face="arial, sans-serif">- This probably will involve
specification changes in order to place the JDK resources
into the </font><font face="monospace">modules</font><font face="arial, sans-serif"> image. Particularly, the </font><font face="monospace">conf/*</font><font face="arial, sans-serif">
resource files were intended to be user configurable
(pointed out by Alan). Alan has been looking into those
parts.</font></div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote type="cite" cite="mid:CALrW1jwSvmMFGp_2_SxJkhMyunp8cz6MrAkHU4wt0CNK0k46-g@mail.gmail.com">
<div dir="ltr">
<div><font face="arial, sans-serif"><br>
</font></div>
<div><font face="arial, sans-serif">- Where should the resources
be placed within the </font><font face="monospace">modules</font><font face="arial, sans-serif"> image? For example, if </font><font face="monospace">conf/security/java.security</font><font face="arial, sans-serif"> is written (using the new <span class="" id=":7pu.2" tabindex="-1" role="menuitem" aria-haspopup="true" style="">jlink</span> plugin) into
the image as </font><font face="monospace">/java.base/java.security</font><font face="arial, sans-serif">, runtime can just access
"java.security" resource using the "java.base" module (via </font><font face="monospace">getResourceAsStream()</font><font face="arial, sans-serif">). Alternatively, if the file is
written as </font><font face="monospace">/java.base/conf/security/java.security</font><font face="arial, sans-serif">, the </font><font face="monospace">conf/security</font><span style="font-family:arial,sans-serif"> package needs to be
added for the </span><font face="monospace">java.base</font><span style="font-family:arial,sans-serif"> module.</span></div>
<br>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
-Alan<br>
<br>
</body>
</html>