"We're not there yet but eventually it should be possible to run a tool
on JDK 9 to access another JDK 9 run-time image (maybe it has a
different set of modules) or run on JDK 9 to access a JDK 10 run-time
image. "
It's disappointing, to say the least, that this wasn't fleshed out for
the upcoming Java9 release. It essentially means that maintainers will
have to rework their code twice. Once for the release of Java9, and once
again when the ability to read another JDK's runtime image becomes a
reality (Java10?). Also, the fact that the container format is
"implementation-specific" and "subject to change without notice" is also
a major red-flag. I suspect that many developers are going to have
issues migrating to Java9 due to tool breakages (findbugs, etc..).
On 7/2/2015 12:57 PM, Alan Bateman wrote:
On 02/07/2015 20:01, [email protected] wrote:
The JEP says that the module container format is
"implementation-specific" and "subject to change without notice". My
concern is that this is going to end up screwing over tool
maintainers, such as myself. I maintain an opensource tool that scans
through core Java classes for instrumentation purposes. It's supposed
to be able to target code written for Java 1.4 and above. I can force
my users to use Java9 to run the tool, which means that that the tool
will be able to read core Java9 classes via the jrt:/ URL solution.
But what happens when Java10 comes out? Will my users be able to scan
core classes in Java9 if the tool is running on Java10?
So far, it looks like nothing in the JEP covers this. As far as I can
tell, the jrt:/ URL solution only reads core classes/resources from
the version of Java that the tool is running on.
Search for "jrt-fs.jar" in the JEP. As things stand in JDK 9 then you
run the tool on JDK 8 to access the contents of a JDK 9 run-time image
or run the tool on JDK 9 to access itself.
We're not there yet but eventually it should be possible to run a tool
on JDK 9 to access another JDK 9 run-time image (maybe it has a
different set of modules) or run on JDK 9 to access a JDK 10 run-time
image.
-Alan.
