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

[mark.reinhold at oracle.com]

2014/11/21 1:47 -0800, mark.reinhold at oracle.com:
> 2014/11/20 6:23 -0800, alan.bateman at oracle.com:
>> On 17/11/2014 20:23, Andrey Loskutov wrote:
>>> :
>>> 
>>> If FindBugs needs to read the bytecode of the java.sql.Array class from JDK 9,
>>> how we can address it *without* knowledge to which module it belongs? We would
>>> never know the module names, but only class names from bytecode, or I'm wrong
>>> here?
>>> 
>>> At the end, the *only* reliable way to get the bytecode of the class file for
>>> a given class name from JDK 9 classes would be to use the
>>> Classloader.getSystemResource("full/qualified/class/Name.class") and this will
>>> mean: to analyze JDK 9 we *must* run on JDK 9?
>>> 
>>> I'm missing something trivial?
>> 
>> There is some TBD here, most likely the file system will need to provide 
>> file paths to get to the class files without knowing the module name.
> 
> Yes.  Here's what we're thinking.  Paths in the "jrt:/" NIO filesystem
> are currently of this form:
> 
>   /$MODULE/$PATH
> 
> where $MODULE is a module name (e.g., "java.base") and $PATH is the name
> of a resource, most often the binary name of a class.
> 
> Let's add a directory level, and support two forms:
> 
>   /modules/$MODULE/$PATH
>   /packages/$PACKAGE/$MODULE
> 
> where $PACKAGE is a package name (e.g., "java.lang").  A path of the
> second form names a symbolic link which, in turn, points to the
> directory under /modules that contains a module that defines that
> package.  ...

FYI, I've created https://bugs.openjdk.java.net/browse/JDK-8066492 to
track this.  We won't have time to get this into the Jigsaw m2 forest
before the upcoming initial integration into JDK 9, but this should
show up in JDK 9 shortly thereafter.

- Mark