Annotation discovery JEP

[Gunnar Morling]

Big +1 for having such functionality in a standardised form. It'll be very
useful for implementors of annotation centric APIs such as JPA, Bean
Validation or CDI.

>  Are there any use-cases for discovering arbitrary annotations? etc.

Yes, e.g. Bean Validation allows users to define their own constraints,
which are custom annotations (in general recognisable from being
meta-annotated with @Constraint). CDI has custom custom qualifier
annotations. For such use cases it'd be very useful to be able to search
for annotated elements by giving such meta-annotation.

2017-12-01 17:14 GMT+01:00 Greg Wilkins <gregw at webtide.com>:

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