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