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

[A. Sundararajan]

This is what javac and rmic in jigsaw/m2 forest do. But, every tool has 
to repeat same walk-read-infer-cache business. Top level /packages, 
/modules and the symlinks is to support a standard way to read this info 
without having to walk/infer/cache.

-Sundar

Remi Forax wrote:
>
> On 11/21/2014 10:47 PM, mark.reinhold at oracle.com wrote:
>
> [...]
>> 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.  Example:
>>
>>    /packages/java.lang/java.base -> /modules/java.base
>>
>> To find java/sql/Array.class without knowing its module you look up
>> /packages/java.sql, which is a directory, and enumerate its entries.
>> In this case there will be just one entry, a symbolic link named
>> "java.sql", which will point to /modules/java.sql, which will contain
>> java/sql/Array.class.
>>
>> The reason for having /package/$PACKAGE be a directory of symbolic links
>> to module directories rather than such a symbolic link itself is that in
>> some scenarios multiple modules will contain packages of the same name.
>>
>> - Mark
>
> I'm not sure we need a special secondary directory branch,
> a tool interested by this kind of information can easily read all the 
> files of all the modules and
> create an index.
>
> Maybe, there is something that I don't understand ?
>
> Rémi
>