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

[Remi Forax]

On 11/16/2014 06:26 PM, Alan Bateman wrote:
> 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.

As you said, having a jrt provider for rt.jar (and the other jars) will 
be great but a jrt-fs-backport.jar able to read the last jimage version 
and compatible with 7 is in my opinion enough.

>
>
>> 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.

While i agree that the jimage format will change, tools developers will 
be mostly interested by the last version
so this is not as bad as you may think.
And BTW, I'm more worry about tools developers not recognizing the 
jimage format at all.

>
>
>>
>> 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.

yes, my bad.

>
> -Alan

Rémi