Arjan Tijms wrote on 09/19/17 01:29 PM:
On Tue, Sep 19, 2017
at 12:09 pm, Bill Shannon wrote:
I'm not sure if there's any inconsistency, other than creating
literals for the JSR 330 spec and including them in 299. Or is
that what you're referring to?
The CDI expert group didn't raise
this at the platform level, and they didn't even do this
consistently for their annotations
Some of the annotations have literals and some do not. There may be
some rationale for why only some of the annotations need literals,
but it wasn't explained.
They're mostly used for the various builders that CDI has for
dynamically adding annotations to beans. CDI already has a helper
class for that that makes it somewhat easier (https://docs.jboss.org/cdi/api/2.0/javax/enterprise/util/AnnotationLiteral.html),
but even with the helper class it's still a bit verbose.
, so I'm not clear on what their
intent is with these annotation instances. How would
applications use them?
For a practical example see: http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html
It's also used for lookups, as in this code:
For the full context see: https://github.com/javaee-samples/javaee8-samples/blob/master/cdi/qualified-lookup/src/test/java/org/javaee8/cdi/qualified/lookup/QualifiedLookupTest.java#L41
In that latter example a bean is selected that has the
@Named("northern") annotation applied to it.
Hopefully this is very much an advanced case and not something that
typical applications will need to do.
Perhaps, but without members the annotation instance is a totally
static singleton, like enum values basically. With members this is
obviously not the case.
If there's a reason applications
need to be able to create annotation instances, wouldn't it be
better if it worked the same whether or not the annotation has
If an annotation evolves to have members, would you still want a
static instance? Wouldn't it be simpler if there was always just
one way to get an instance?
Possibly indeed, but not sure how feasible it is to get that in.
Maybe this really belongs in the
For now Java EE support throughout all applicable specs (basically
the specs that already leverage CDI) isn't that hard at all. Had I
learned about this annotation literals a tiny bit earlier I could
have added them trivially to JSF and Java EE security (if the spec
lead and EG would have agreed, of course).
Depending on each spec to do it means that some won't.
This is not the first thing about annotations that we wished every
spec would handle. I really wish we could push more of this into
the JDK, or find a way to centralize all of this in a place that
would apply to all Java EE uses of annotations automatically.
Lacking that, a "design pattern" as you suggest might be the best
approach. Another item for the future Eclipse project to address!