Annotation discovery JEP

David Lloyd david.lloyd at redhat.com
Fri Dec 1 14:52:23 UTC 2017


On Fri, Dec 1, 2017 at 8:44 AM, 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

Hi Greg.  I just want to add that back when this was being discussed
for Jigsaw, I recall that we talked about a meta-annotation (e.g.
"@Indexed") that would need to be present on the annotation type for
it to be indexed.  If present, then the compilation stage would
probably add the relevant information to some index within the JAR,
module, etc. which would be discoverable by some runtime
reflection-ish API.

It would be nice however if it were not limited to code using JPMS modules.

I'm definitely in favor of getting this missing bit in, at any rate.

-- 
- DML


More information about the discuss mailing list