Scanning Modules(take 2)?

Greg Wilkins gregw at webtide.com
Wed Nov 29 09:33:39 UTC 2017


Back in September I asked a couple of questions about scanning modules (for
annotated classes):

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-September/013178.html

Thanks for the answers, which have been helpful, but now a supplementary
question/suggestion.

Given that many java technologies (not just EE) need to scan jars for
annotated classes, is it possible for this to be a semantic provided by the
module system?  Currently multiple  java frameworks are implementing code
that asks for lists of modules, then lists of classes within those modules,
then finding the raw bytes of those classes and passing them to something
like ASM to determine how they are annotated in order to drive their
configuration.  This code can be rather complex and probably fragile when
you consider issues like:

   - multi release jars (specially as sometimes one JVM might need to
   process meta data to be deployed on a different java platform)
   - classpath vs module path vs upgrade paths etc
   - observable vs resolved vs platform modules
   - layers
   - jlink


Currently frameworks are having to reimplement much of the logic to
determine exactly what classes a JVM will resolve for a given environment.
The chances are low of every frameworks getting this right and doing so in
a way that is future proof as these features evolve through java 9, 10, 11.

So perhaps it would be a good idea for the library to provide some
semantics to assist frameworks to get this right?  Ideally there would be
an API to allow frameworks to query the JVM about what classes (which may
not be loaded and may even be for a different target platform) it can see
that are annotated in a particular way.

thoughts?


-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com


More information about the jigsaw-dev mailing list