The 'modules' image (jimage) packaged JDK resources

[Jiangli Zhou]

Thanks, Alan! This clarifies things quite a bit.

On Wed, Jan 31, 2024 at 3:01 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:
>
> 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 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.
>
> 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.
>
>
> 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.
>

Thanks for the example. Looking closely at Class.getResourceAsStream
<https://github.com/openjdk/jdk/blob/2cd1ba6a52eafffa65d0f2532a07fff89f9cea0e/src/java.base/share/classes/java/lang/Class.java#L3063>,
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 modules
image) the resources from lib/ with the classes that accessing the
resources as you suggested is the cleanest.  As an example,
lib/security/blocked.certs (used by sun.security.util.UntrustedCertificates)
can be located as /java.base/sun/security/util/blocked.certs within the
modules file.

One other related thought/question, any potential issues if we place the
lib/ resources in modules by default for regular JDK, instead of just for
static images?

>
> 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 modules image. 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 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.
>
> 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.
>

Yeah, java.security can be overridden by java.security.properties specified
security property file if security.overridePropertiesFile is true. In that
sense, users should provide their own property file instead of modifying
the master security property file. It seems we may want to put
java.security in the modules as /java.base/java/lang/security/java.security?

Thanks!
Jiangli

> 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/16fe4b92/attachment.htm>