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 06:01 AM, A. Sundararajan wrote:
> 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

In a module world, when you want to compile something, you only need to 
take a look to the few modules declared as dependencies. So in a module 
world, you don't need the walk-read-infer-cache thing as you name it.
It's when you are not in a module world and you want to be compatible 
with the module world too that you need to gather all packages of all 
modules.

So I don't think it's a good idea to add the package branch given that 
you need it only to be compatible with the old with-no-module world (and 
IDEs, but each IDE already have a specific way to index the whole world 
anyway).

cheers,
Rémi

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