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
