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

[Remi Forax]

I agree that a flat file created at install time is a better solution.

Rémi

On 11/23/2014 01:01 PM, Andrey Loskutov wrote:
> I'm with Sundar: without extra help FindBugs (and any other "old" tool/IDE)
> would need to always spend extra time to index the "jrt:/" file system and to
> persist the results somewhere (per user!), spending extra code to proper
> database locking to avoid concurrent access etc.
>
> Just wondering if the package->modules map (in the default properties format)
> couldn't be just saved as a plain text file in the root of the jdk (or any
> other suitable place)? The benefit related to the symlink approach is that the
> access to such map would be much faster (single I/O read vs directories
> traversal).
>
> The performance/code overhead of creating and maintaining default package-
>> modules map per JDK/user can be moved to the JDK build or install time,
> making all clients happy, and the code required in the JDK to generate and
> save such map once at build/install time is probably trivial, because there is
> no need for locking at all.
>
> On Sunday 23 November 2014 11:25:44 Remi Forax wrote:
>> 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