Module container format

[mark.reinhold at oracle.com]

2015/7/2 9:16 -0700, 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..).

The whole point of the virtual "jrt" file system (and related URLs) is
to provide access to the classes and resources inside a run-time image
in a way that's fully independent, across releases, of the image format.
No external code should attempt to read the guts of an image directly,
rather it should load and use the file system in that image's jrt-fs.jar
file.  The jrt-fs.jar file in JDK N will always run on JDK N-1, and also
on all later releases.

If there's something further you need from the jrt file system then let
us know, so we can figure out how to expose it.

- Mark