Annotation discovery JEP

Greg Wilkins gregw at
Mon Dec 11 12:53:40 UTC 2017

Thanks all for the feedback on this.  I've sent the draft to jep-submit,
however I think the process has changed and I may need a openjdk committer
to progress the JEP? If so, anybody interested?


On 1 December 2017 at 15: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

Greg Wilkins <gregw at> CTO

More information about the discuss mailing list