Annotation discovery JEP

Stephen Colebourne scolebourne at
Fri Dec 1 14:57:55 UTC 2017

I believe this would be a very valuable addition.

On 1 December 2017 at 14:44, Greg Wilkins <gregw at> 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
> <>,
> 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
> <>
> :
> *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
> <>".
> 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> CTO

More information about the discuss mailing list