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

[Andrey Loskutov]

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

-- 
Kind regards,
google.com/+AndreyLoskutov