Annotation discovery JEP

[Greg Wilkins]

David,

I've seen such discussions.  Perhaps that could have been done if it was
added from day 0, but there are already
modules in the wild with annotations that need to be scanned which will not
have any index.

So I think we are going to need to support full discovery at runtime with
any metadata indexes just being optional optimisations rather that required
element.

We also need to have a bit of a review of the discoverable annotations that
exist to determine if it really is known at compile time which ones need to
be discoverable.  Are there any use-cases for discovering arbitrary
annotations? etc.

I also agree that it would be good if it could be on more than just
modules.  It is exactly the difficulty of determining which classes are
resolved when there are normal jars/classes on the classpath as well as
module paths/updates/boots that motivates this suggestions.   So 0 modules
and all classpath is just an edge case of that requirement.   I currently
think that we should either be able to ask a classloader for what annotated
classes it would load, or pass a classloader to the API to ask it what
annotated classes it could load.... but these are early thought bubbles.

cheers







On 1 December 2017 at 15:52, David Lloyd <david.lloyd at redhat.com> wrote:

> 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
>



-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com