2014/11/20 6:23 -0800, alan.bate...@oracle.com:
> On 17/11/2014 20:23, Andrey Loskutov wrote:
>> :
>>
>> If FindBugs needs to read the bytecode of the java.sql.Array class from JDK
>> 9,
>> how we can address it *without* knowledge to which module it belongs? We
>> would
>> never know the module names, but only class names from bytecode, or I'm wrong
>> here?
>>
>> At the end, the *only* reliable way to get the bytecode of the class file for
>> a given class name from JDK 9 classes would be to use the
>> Classloader.getSystemResource("full/qualified/class/Name.class") and this
>> will
>> mean: to analyze JDK 9 we *must* run on JDK 9?
>>
>> I'm missing something trivial?
>
> There is some TBD here, most likely the file system will need to provide
> file paths to get to the class files without knowing the module name.
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
