users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely

From: David Blevins <david.blevins_at_gmail.com>
Date: Tue, 4 Sep 2012 14:59:04 -0700

On Sep 1, 2012, at 12:21 AM, Werner Keil wrote:

> David,
>
> Thanks for the example.
> Especially @Schedule most likely would be a candidate for EE8, given a new Date/Time API won't be available before Java 8.

Thanks, Werner. Note the @Schedule annotation was a reference to the javax.ejb.Schedule annotation introduced in EJB 3.1. We actually discussed at that time adding @Daily, @Montly, @Yearly, etc. annotations to correspond with the like cron aliases. We took a conservative "wait and see" and held off.


-David

> We discussed that in the State Management EG, where states being valid for a certain period face similar issues and requirements.
>
> Werner
>
> Am 01.09.2012 02:39 schrieb "David Blevins" <david.blevins_at_gmail.com>:
> General note on duplication. We have duplication already.
>
> Really the question is how do we address the duplication or if we address it.
>
> The annotation inheritance concept exists in other specifications such as Bean Validation and JAX-RS. Here's how JAX-RS defines @POST, as a Stereotype/Metatype of @HttpMethod.
>
> @Target(value=METHOD)
> @Retention(value=RUNTIME)
> @HttpMethod(value="POST")
> public @interface POST
>
> The only thing missing is @Stereotype/_at_Metatype.
>
> If we want to do this in more specifications, for example in EJB add
>
> @Target(value=METHOD)
> @Retention(value=RUNTIME)
> @Schedule(second = "0", minute = "0", hour = "*", month = "*", dayOfWeek = "*", year = "*")
> public @interface Hourly
>
> How would we want to do that?
>
> Fundamentally there are three options:
>
> a) address duplication by requiring @Stereotype and CDI dependency
> b) address duplication by introducing one more duplicate (let's be fair), @Something in a common annotation or new spec
> c) don't address duplication, specifications can duplicate the reuse concept, some require CDI some do not
>
>
> -David
>