Hi,
The situation is not different from, say, zip/jar file system - that
file system too exposes *all* underlying resources via file system. All
.class resources - package private classes, anonymous inner classes etc.
are exposed. Language notions like public/package-private/anonymous etc.
have to be found only by reading appropriate .class resources.
Similarly, module export/requires/use information has be to be found
only reading & parsing module-info.class resources. Repeating that info
at file system level is problematic - redundancy, potential
inconsistency...
Thanks.
-Sundar
On 10/19/2015 5:42 PM, Philippe Marschall wrote:
Hi
I'm toying around with the jrt filesystem [1]. I noted that non-API
classes are shown for java modules (see attachment). I assume this is
because jrt currently reports all classes in a module, not just the
exported ones (and these classes are not exported). Assuming this is
the intended behavior this is a bit inconvenient. One would have to
parse the module-info.class to find out what is exported. Some
possible solutions could include:
* have a file attribute specific to the jrt filesystem "exported" to
report whether a file/package is exported
* have two subtrees in a module, eg. "all" and "exported"
[1] https://github.com/marschall/jrt-explorer
Cheers
Philippe
