Re: Platform wide guideline for build-in annotation literals?

Arjan Tijms
 

On Tue, Sep 19, 2017 at 12:09 pm, Bill Shannon wrote:
The CDI expert group didn't raise this at the platform level, and they didn't even do this consistently for their annotations
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?


, so I'm not clear on what their intent is with these annotation instances.  How would applications use them?
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.

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:

myGreetings.select(NamedLiteral.of("northern")).get();

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.

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 members? 
Perhaps, but without members the annotation instance is a totally static singleton, like enum values basically. With members this is obviously not the case.

Maybe this really belongs in the JDK...
Possibly indeed, but not sure how feasible it is to get that in.

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

Kind regards,
Arjan Tijms







Arjan Tijms wrote on 9/19/17 9:00 AM:

Sorry, that's not what I meant ;)

What I meant was that each annotation should of course stay within their respective spec. I.e. @Transactional should of course stay in JTA.

But the annotation literal support should be somewhat mandated by the umbrella spec, so that all specs provide those for their annotations (where applicable) and all specs do it in the same way.

For instance, CDI now has:

RequestScoped requestScopedLiteral = RequestScoped.Literal.INSTANCE;

So JSF should get:

ViewScoped viewScopedLiteral = ViewScoped.Literal.INSTANCE;

And not say:

ViewScoped viewScopedLiteral = ViewScoped.getAnnotation();

or 

ViewScoped viewScopedLiteral = ViewScoped.of(ViewScoped.class);

or ...

ViewScoped should of course stay within JSF and nothing should ever move to the umbrella spec. The umbrella spec should only establish a rule saying that annotation literals are to be done via [annotation class].Literal.INSTANCE;

Hope it's more clear now ;)

Kind regards,
Arjan Tijms

 

Join javaee-spec@javaee.groups.io to automatically receive all group messages.