All,
The eclipse jetty project has been progressively implementing java 9 support for features such as multi release jars and modules. It is a surprisingly complex area and has resulting in many discussions on the various JDK dev lists. One such
recent conversation in jigsaw-dev has resulted in the suggestion that we start a project for annotation scanning that may eventually be proposed as new API for a future JVM. My question is, should/could that project be started under EE4J?
The key parts of the conversation are:
Greg Wilkins wrote:
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
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?
Alan Bateman wrote:
This was listed in the JSR 376 requirements document [1] but it didn't happen in Java SE 9. There were suggestions at the time to generate an index at packaging time. There were also suggestions (and some initial prototyping with a jlink plugin) to index at link time. I don't think the efforts got as far as thinking about an API.
So yes, it is an area where there is interest but I'm not aware of anyone working on it just now. If you or others have cycles to create a library and explore the area then it could be useful.
-Alan
[1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detection
Greg Wilkins wrote:
Not so sure we have a lot of cycles, but the eclipse jetty project is already burning cycles now to implement, so in the long run it may be better to put in a few more cycles to make this logic generally accepted.
I'm wondering if perhaps I should suggest as a new project within the eclipse EE4J effort, as that will capture interest, expertise and cycles from several frameworks that could benefit. If successful, it might then live there long term, but I think contribution to a future java platform would be a better home for it as it would benefit from being part of future considerations.
The unimplemented jigsaw requirement says:
Efficient annotation detection — It must be possible to identify all of the class files in a module artifact in which a particular annotation is present without actually reading all of the class files. At run time it must be possible to identify all of the classes in a loaded module in which a particular annotation is present without enumerating all of the classes in the module, so long as the annotation was retained for run time. For efficiency it may be necessary to specify that only certain annotations need to be detectable in this manner.
So that given a lot of projects (Servlet, JPA, CDI, Spring etc.) are all currently struggling to implement annotation scanning under java9, is there scope for common effort? Could it be done under EE4J? Or maybe just another toplevel Eclipse project?
thoughts?
--
