On 16/11/2014 13:47, Remi Forax wrote:
:
I think it's not a good idea to try to embed jrt-fs.jar in older
releases.
If you mean a jrt-fs.jar containing code that is tied to a non-stable
and changing format then I agree (and I don't think there is any
proposal to do that).
If you mean the suggestion in the end of my mail then it was just
pointing out that it wouldn't be hard to create a jrt:/ provider that
provides the same interface for runtime images that internally have
rt.jar, resources.jar, jsse.jar etc. This has the potential to allow the
same API be used over a wider range of major releases than is currently
proposed in the JEP. I could imagine this needing to be well bedded down
and be in shipping 7u and 8u releases for a significant period before
tools would be confident to remove older code that directly accesses
rt.jar etc.
Instead, we can provide
a backport of jrt-fs.jar lets name it jrt-fs-backport.jar, publish it
on maven central
(with the same licence as the OpenJDK) and lets tools that need it to
use it.
My point about a one off backport to JDK 7 is that it will be stale
almost immediately. In order to access the modules, classes and
resources in a JDK 9 runtime image then it requires code that
understands the specific build. I think it would be reasonable to assume
that the container format will change quite a bit during the development
of JDK 9 and therefore the code that knows about this format will change
too.
If jrt-fs.jar is published separately to the promoted builds then it
would require a tool that wants to examine the contents of a target
image to first inspect the target image (maybe the top-level "release"
file) and then locate the jrt-fs that corresponds exactly to that build.
One could hide that behind a JDK-specific API of course but the proposal
is to keep things simple and just include it in the target image to
avoid a separate download.
I have taken a look to the source code of jdk.internal.jimagefs and
jdk.internal.jimage
I suspect you mean jrtfs rather than jimagefs here but one thing to
mention is that the jimagefs code will go away very soon as it was
temporary. That should happen soon after javac, rmic, and jdeps are
switched from jimagefs to jrtfs.
-Alan
