On 30/05/2016 07:47, Jayaprakash Arthanareeswaran wrote:
I got hold of a recent JRE build (jre-9-ea+118) and noticed two things that
were different from the previous JDK builds:
1. There's no jrt-fs.jar. Is this expected? We have use for this for couple
of work around - (a) to recognized this is a JDK/JRE 9 and (b) to get the
class loader and eventually the system libraries.
Is there a way around this?
To date, then jrt-fs.jar has only been copied into the JDK build.
JDK-8153079 [1] tracks examining whether it should be in all runtime
images so as to support cross compilation cases (meaning `java -system
...`). Those creating small runtimes with jlink will probably want to
leave it out of course.
In any case, modules completely blurs the historical distinction between
what we used to know as the JRE and JDK. You can use the jlink tool to
create runtime images that a mix of API and tool modules, it might have
user libraries and applications too. For introspection purposes, the
`release` file in the top-level directory has a key named "MODULES" with
the names of the modules that the runtime image contains. The MODULES
key is documented in JEP 220. Also just to say that the `release` file
was specifically introduced in JDK 7 to allow IDEs and other tools to
get information about a target JDK/runtime without needing to invoke
anything in the target runtime.
If you really really need some way to distinguish a JRE and JDK then
checking if the jdk.compiler module is in the list of module names. This
is very crude of course because you can use jlink to create a custom
runtime image that has the jdk.compiler module.
I'm curious what you mean by "(b) to get the class loader" as there is
no information to know which modules are mapped to which class loaders.
2. I don't see any jimage file or jmod files but just one file named
"modules" without an extension.
That is correct, there is one jimage container file named "modules" now.
-Alan
[1] https://bugs.openjdk.java.net/browse/JDK-8153079
