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

[Remi Forax]

On 11/23/2014 08:29 PM, Andrey Loskutov wrote:
> 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).

The jrtfs-backport.jar works with Java 7. The code use some feature of 
Java 8
(like lambda) thus need to be compiled with Java 8 but those features are
retrofited to be compatible with java 7 by rewriting the bytecode. [1]

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

yes, the jdk home makes more sense,
There is an example about that here [2]

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

I don't think it's really a big deal for Eclipse or any IDE, yes, the 
JDT will
need to be changed to be able to read the image format but unlike findbugs,
this can be done only if the JDK9 is the JDK that run Eclipse so the jrt
filesystem provider will be available. Otherwise, Eclipse could use the 
backport.

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

As you say having a lib/rt.jar is odd and any option that requires an admin
will not solve the issue. I still like the idea of a plain text file 
containing the mapping.

Rémi

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

[1] 
https://github.com/forax/jigsaw-jrtfs/blob/master/backport-build/src/com/github/forax/jrtfs/backport/RetroWeaver.java
[2] https://github.com/forax/jigsaw-jrtfs/blob/master/examples/Test.java