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

[Gregg Wonderly]

There will likely be many more small, unchanging applications than large 
constantly changing applications requiring upgraded code to support new 
standards. There needs to adequate attempt at accommodation of application 
deployment paradigms where having to change API use in the application is a huge 
waste of time, and will be nearly impossible for the author to make it possible 
for "users" to know how to do that (primarily because Java still has no App 
store, but also because more "users" of "software" are often not developers who 
know about releases of fixes and updates).

Jar based deployment has always been a very convenient way to ship Java code 
that didn't need odd startup control, such as command line parameters for 
policy, URL handlers etc.  And, even some of those things could be done at run 
time quite readily.

If all Oracle and the OpenJDK community wants, is to use Java for "server apps" 
where deployment and management have significant administrative overhead, then 
that will significantly reduce the buy in to any "new paradigm" for Java deployment.

The desktop environment is still horribly ignored as a place where Java could 
really provide great user experiences, if the UI strategy was part of the work 
that people invested in getting right.

This strategy for "packaging" Java could allow custom UI work to be done and 
substituted into the runtime environment so that more investigation and work 
could happen toward fixing all the plethora of problems that have manifested 
from there only being a single, closed system for UI "improvement".

Gregg Wonderly

On 11/16/2014 7:47 AM, Remi Forax wrote:
>
> On 11/15/2014 11:18 AM, Alan Bateman wrote:
>> On 14/11/2014 16:34, Bill Pugh wrote:
>>> Following up on a email thread started by Dalibor Topic…
>>>
>>> In short, back porting jrt-fs.jar to work under Java 7 would be very helpful 
>>> to the FindBugs project.
>>>
>>> At length:
>>>
>>> FindBugs needs access to the classifies for the standard Java libraries in 
>>> order to analyze code. Right now, we access that through the file system, 
>>> but that won’t be possible under jigsaw and JEP 220: Modular Run-Time Images.
>>>
>>> The JRL file system is what is recommended and needed to support FindBugs 
>>> access to standard library classifies under Java 9. Having to support two 
>>> different mechanisms for accessing standard library classifies would be 
>>> annoying. We could move entirely over to the JRL file system. However, 
>>> FindBugs is committed to running under Java 7 for a long time, at least 
>>> several more years, and it would be good if FindBugs support for Java 9 were 
>>> available within a year, if not sooner.
>>>
>>> So, if  jrt-fs.jar ran under Java 7, we could just rewrite that section of 
>>> FindBugs to use the JRL file system, and have one version of the code 
>>> running for Java 7+.
>>
>> If the jrt file system provider could run on JDK 7 then it would just mean 
>> that a tool running on JDK 7 could access the class files and resources in a 
>> JDK 9 image. So I think this would mean that FindBugs would need to keep its 
>> existing code so that it can get to class files in JDK 7 and JDK 8 runtime 
>> images.
>>
>> As to whether it could run on JDK 7 then it could be made to work but would 
>> require dropping the use of newer Java Language and APIs in the 
>> implementation. It would also require a few contortions in the build as JDK 9 
>> uses a JDK 8 for bootstrapping (we always use a JDK N-1 as the boot JDK). 
>> Also just to say that a one-off back-port for JDK 7 wouldn't work as the JDK 
>> 9 image format is intended to change and evolve, hence a build of jrt-fs.jar 
>> in JDK 9.0.0 may not work with a JDK 9.0.1. This means that for now at least, 
>> tools have to use the jrt-fs.jar in the JDK 9 image that they want to access.
>>
>> The only way that I think would be possible to avoid two mechanisms is for 
>> future JDK 7 and JDK 8 updates to include a jrt-fs.jar that works in the same 
>> way but makes it transparent that the classes and resources are coming from 
>> rt.jar, resources.jar, jsse.jar etc. Even then, I would assume that FindBugs 
>> and other important tools wanting to keep the existing mechanism so they can 
>> work on existing JDK 7 and JDK 8 versions.
>>
>> -Alan.
>
> First, I think we should provide a good answer to that question,
> anything that can smoother the integration of jigsaw will increase its 
> adoption rate.
>
> I think it's not a good idea to try to embed jrt-fs.jar in older releases. 
> 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.
>
> I have taken a look to the source code of jdk.internal.jimagefs and 
> jdk.internal.jimage and
> i think such backport is possible with an automatic tool if we stick with the 
> following rules
> for the development of the two packages:
>  - you are allowed to use lambdas and functional interfaces declared inside 
> java.util.function
>    so API like j.i.jimage.Archive that use things like Consumer in public 
> methods is fine.
>  - you are not allowed to use any default methods introduced in JDK8 (Stream 
> API, by example)
>    nor to use ReflectiveOperationException because this requires to patch 
> existing JDK classes.
>
> Given the current source code, I don't think it's a big deal to refactor it a 
> little to avoid
> the use of the Stream API (BTW, there is a method forEach on Iterable, you 
> don't have
> to create a Stream for it, and instead of Array.asList(foo).stream(), there is 
> a method
> Arrays.stream() for that) and it can write the tool that does the retro-weaving.
>
> cheers,
> Rémi
>
>