Annotation discovery JEP

[Stephen Colebourne]

I believe this would be a very valuable addition.
Stephen


On 1 December 2017 at 14:44, Greg Wilkins <gregw at webtide.com> wrote:
> 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