Module container format

[offbynull-jigsaw at offbynull.com]

"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, offbynull-jigsaw at offbynull.com 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.
>