Annotation discovery JEP (original) (raw)

Greg Wilkins gregw at webtide.com
Fri Dec 1 14:44:07 UTC 2017

All,

I'm not at all familiar with your processes here, but it has been suggested to me that I should create a JEP to try to initiate a common effort to standardise annotation discovery.

I have created a draft JEP <https://github.com/jetty-project/annotation-discovery/blob/master/JEP-Proposal.md>, which is very light on detail, but I hope it at least well captures the motivation, reproduce here:

Motivation

Prior to Java 9, many java technologies implemented annotation discovery by inspection of either the URLs of the classloader and/or the class path itself and tools such as ASM where then used to parse the byte code for annotations without loading the classes. With the introduction of java 9, which included Modules, Layers, Upgrade paths, Jlink and Multi Release jars, the task of discovering class has become difficult to both specify and implement.

Efficient annotation discovery was an identified requirement of project Jigsaw <http://openjdk.java.net/projects/jigsaw/spec/reqs/#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.

However as explained in the mailing list, this requirement "didn't happen in Java SE 9 <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-November/013363.html>". Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring etc.) are currently reverse engineering the algorithms implemented by the JVM for resolving the modules available at runtime and which classes within those modules are available for loading by the specific runtime platform. Such duplicated effort is unlikely to be correct given the complex nature of module resolution, nor future proof given the intention to release java 10 and 11 within the next year.

I'd appreciate any feedback on the form or substance of this proposal before I submit it

regards

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

More information about the discuss mailing list