Annotation discovery JEP

[Greg Wilkins]

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