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

[Andrey Loskutov]

On Sunday 23 November 2014 18:58:26 Remi Forax wrote:
> On 11/23/2014 05:42 PM, Alan Bateman wrote:
> > On 22/11/2014 20:38, Remi Forax wrote:
> >> This seems to work at least on my laptop :)
> >> 
> >>   https://github.com/forax/jigsaw-jrtfs
> >> 
> >> I end up writing a small tool that backport the source of JDK9 with
> >> no modification
> >> and re-implementing the necessary API pieces of the Java 8 used by
> >> jrt-fs.
> > 
> > So did you get FindBugs working with it too? If so then I'm interested
> > to hear if it is was much effort.
> 
> No, I haven't tried to modify findbugs.
> I have never take a look to the source code and this is not a small project.
> As you I'm interested to hear the story when someone will do that.
> > -Alan
> 
> Rémi

Unfortunately FindBugs would not be able to use your jigsaw-jrtfs project 
because FindBugs must be able to run on Java 7 and your project requires Java 
8 (at least I saw few lambda's here and there). Any chance to port it back to 
Java 7?

FindBugs itself will support Java 7 for quite some time (we just dropped Java 
6 support).

Given Java 7 support in jigsaw-jrtfs (or ignoring Java 7 compatibility for 
FindBugs) one could try to integrate "jfs" support to FindBugs similar to the 
"jar/zip" support, see for example ZipFileCodeBase.java at [1]. But here the 
fun begins: we can either "wrap" entire "jfs" root as one single code base - 
which makes perfect sense - but then wee need to know package to module 
relationship as discussed earlier; or we somehow can get the list of modules 
and then threat each module as a special "Java 9 jar" blob (which doesn't make 
much sense for me).

Implementing both based on your code and ignoring Java 7 constraint is 
probably not a big deal. What we additionally need is to change our command 
line arguments (or the parser [2,3]). Today user can specify JDK libraries to 
be analyzed by FindBugs together with the application code - of course this 
code assumes that those files are in jar/zip format. We need to change the 
logic here to and to allow user specify extra JDK 9 ".jimage" files (don't 
make much sense for me) or to provide extra argument with JDK system root to 
use during analysis.

Given that above we can have jfs support in FindBugs *command line* 
application pretty fast.

What makes more work is that the two FindBugs UI's must be adopted too - Swing 
and Eclipse - they have today no clue about "jfs" way to specify class files. 

The biggest issue we will probably have here with the FindBugs Eclipse UI 
because Eclipse JDT project must adapt their code too and add support for 
modules and jfs (BTW I highly recommend you to involve JDT guys in the 
discussion here - added Stephan to CC). The future JDT changes for module 
support will most likely break existing Eclipse API (you cannot map "module" 
or "jfs" to jar 1:1), which means the FindBugs Eclipse plugin (any all other 
JDT based plugins) will not be able to support both pre-Java 9 JDK's and Java 
9 at same time or we will lost backwards compatibility. However we want stay 
backwards compatible to few recent Eclipse versions (at least). This is 
*really* pity situation.

Looking on the changes required to make FindBugs/Eclipse happy with new Java 9 
structure (modules/jfs) I would like to ask here: why couldn't we extract all 
JDK 9 classes on installation from "jfs" to the "legacy" lib/rt.jar location? 
This sounds odd because it duplicates classes but this could help 3rd party 
tools/IDE's to "survive" incompatible JDK structure changes in JDK 9 for some 
time. May be this can be also done as a new "-createLegacyJars" argument for 
java CLI to allow admins install java support for "legacy" tooling? What do 
you think?

[1] 
https://code.google.com/p/findbugs/source/browse/findbugs/src/java/edu/umd/cs/findbugs/classfile/impl/ZipFileCodeBase.java
[2] 
https://code.google.com/p/findbugs/source/browse/findbugs/src/java/edu/umd/cs/findbugs/Project.java#1043
[3] 
https://code.google.com/p/findbugs/source/browse/findbugs/src/java/edu/umd/cs/findbugs/classfile/impl/ClassFactory.java

-- 
Kind regards,
google.com/+AndreyLoskutov