Support for jrt-fs.jar in JDK 7 would be very helpful in allowing FindBugs to run under Java 9

[Alan Bateman]

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