Hi, As a tool developer (in my case it's the "forbidden-apis" tool [*], used to disallow certain API signatures in compiled code), it would also be good to allow differentiating between real JDK runtime modules (those that are public and part of the JDK) from those which are 3rd party plugins maybe linked into the runtime image, but that are not part of the official JDK / Java spec.
If this is already possible it would be good to find out how to do this. Currently I look at module name and check that it starts with "java." (like "java.base") Uwe [*] https://github.com/policeman-tools/forbidden-apis ----- Uwe Schindler [email protected] ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: jigsaw-dev [mailto:[email protected]] On Behalf > Of Jonathan Gibbons > Sent: Monday, October 19, 2015 7:25 PM > To: [email protected] > Subject: Re: non-API classes displayed by jrt filesystem > > > > 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
