On 10/19/2015 06:57 AM, Alan Bateman wrote:
On 19/10/2015 13:12, 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"
The behavior you see is intended and as Sundar said, it's not really
something for the file system to be concerned about. Also remember
there are qualified exports in the design and it would really
complicate things for the file system is be concerned with that.
In any case, I think explorers are going to be useful to developers
because the module graph is essentially a new API to learn. If you are
only interested in the runtime that the tool is running on then you
might find ModuleFinder.ofInstalled().findAll() useful.
-Alan
In time, javax.lang.model should also provide a way of examining modules
that are distinct from those in the running system.
-- Jon
