<div dir="ltr">Thanks, Alan! This clarifies things quite a bit.<br><br>On Wed, Jan 31, 2024 at 3:01 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>> wrote:<br>><br>> On 31/01/2024 01:41, Jiangli Zhou wrote:<br>><br>> As part of the discussions of bringing <a href="https://github.com/openjdk/leyden/tree/hermetic-java-runtime" target="_blank">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 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 class using a ZipFileSystem. If JDK resources are part of the modules, the static/hermetic image packaging and runtime accessing becomes further cleaner.<br>><br>> I recently prototyped that idea with a jlink plugin and some quick runtime changes to access using Module.getResourceAsStream (not in the hermetic-java-runtime branch yet). The quick prototype indicates it is feasible from an implementation point of view. <br>><br>><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>><div><br></div><div>Thanks for the example. Looking closely at <a href="https://github.com/openjdk/jdk/blob/2cd1ba6a52eafffa65d0f2532a07fff89f9cea0e/src/java.base/share/classes/java/lang/Class.java#L3063" target="_blank">Class.getResourceAsStream</a>, I see it resolves the full resource name by prepending the package name of the current class if necessary. So it looks like co-locating (in the <font face="monospace">modules</font> image) the resources from <font face="monospace">lib/</font> with the classes that accessing the resources as you suggested is the cleanest.  As an example, <font face="monospace">lib/security/blocked.certs</font> (used by <font face="monospace">sun.security.util.UntrustedCertificates</font>) can be located as <font face="monospace">/java.base/sun/security/util/blocked.certs</font><font face="arial, sans-serif"> within the </font><font face="monospace">modules</font><font face="arial, sans-serif"> file.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">One other related thought/question, any potential issues if we place the </font><font face="monospace">lib/</font><font face="arial, sans-serif"> resources in </font><font face="monospace">modules</font><font face="arial, sans-serif"> by default for regular JDK, instead of just for static images? </font></div><div><br>><br>> Following are a few points that have been discussed among us for more broad discussions:<br>><br>> - This probably will involve specification changes in order to place the JDK resources into the modules image. Particularly, the conf/* resource files were intended to be user configurable (pointed out by Alan). Alan has been looking into those parts.<br>><br>><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>><br>> - Where should the resources be placed within the modules image? 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/security package needs to be added for the java.base module.<br>><br>> 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>></div><div><br></div><div>Yeah, <font face="monospace">java.security</font> can be overridden by <font color="#000000"><span style="white-space:pre-wrap"><font face="monospace">java.security.properties</font><font face="arial, sans-serif"> specified security property file </font></span></font>if<font color="#000000"><font face="arial, sans-serif"> </font><span style="white-space:pre-wrap"><font face="monospace">security.overridePropertiesFile</font><font face="arial, sans-serif"> is true. In that sense, users should provide their own property file instead of modifying the master security property file.</font><font face="arial, sans-serif"> It seems we may want to put java.security in the </font><font face="monospace">modules</font><font face="arial, sans-serif"> as </font><font face="monospace">/java.base/java/lang/security/java.security</font><font face="arial, sans-serif">?</font></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap"><font face="arial, sans-serif"><br></font></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap"><font face="arial, sans-serif">Thanks!</font></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap"><font face="arial, sans-serif">Jiangli</font></span></font></div><div><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.</div><div>><br>> -Alan<br>><br></div></div>