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.reinh...@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
