Possibly I misunderstood you. I meant we would need to specify that
the annotations to which we add the ANNOTATION_TYPE target would need
to be specified as usable as meta-annotations, it's not enough to just
add the target to them... We would need to specify whether they can be
applied recursively or not etc.
On 15 December 2011 02:51, Marina Vatkina <marina.vatkina_at_oracle.com> wrote:
> Do you mean various synonims or the @Metatype?
>
>
> Pete Muir wrote:
>>
>> Surely to give users that option in a portable fashion, we need to spec
>> it?
>>
>> On 14 Dec 2011, at 04:37, Marina Vatkina wrote:
>>
>>
>>>
>>> We can add ANNOTATION_TYPE (to all or to a subset of annotations). I
>>> think we shouldn't spec such meta-annotations, but rather give users an
>>> option to add annotations if they like it that way.
>>>
>>> But the "simplified" @Schedule versions can be confusing though, e.g.
>>> @Daily or @Yearly will need more details, like time of the day or day of the
>>> year, in which case they wont be shorter than the original - @Schedule() is
>>> daily at midnight, and @Schedule(dayOfMonth="1", month="1") is yearly on Jan
>>> 1st...
>>>
>>> My $.02. What do others think?
>>>
>>> Best,
>>> -marina
>>>
>>> David Blevins wrote:
>>>
>>>>
>>>> I think this is too big for this spec round, but here is the idea in
>>>> more clear terms.
>>>>
>>>> Yes, it is very much like CDI stereotypes. It's also very much like
>>>> Bean Validation's ability to reuse annotations. It's also like CDI
>>>> @InterceptorBinding and @Qualifier which also have "meta" effects associated
>>>> with them -- i.e. annotations that use them effectively become
>>>> @InterceptorBindings and @Qualifiers.
>>>>
>>>> We're doing this all over the place really. It's not entirely CDI or
>>>> Bean Validation specific. It's not EJB specific either, so let's try not to
>>>> look at it and get distracted with the whole align EJB and CDI initiative.
>>>>
>>>> The twist here is that you can "reuse" annotations which aren't designed
>>>> to be applicable to @Target(ANNOTATION_TYPE). The syntax for it is IMO ugly
>>>> but effective. If we don't want that twist, we can easily go simpler.
>>>>
>>>> This is really a design pattern and not specification specific. If
>>>> there is an idea of specification, it would be a Java SE -- it would be
>>>> quite handy to be able inherit annotations in this fashion at a language
>>>> level and not need the cooperation of specific apis.
>>>>
>>>> For our purposes, we could just as easily decide to add ANNOTATION_TYPE
>>>> to all our current annotations and make a simple rule that "annotations with
>>>> the ANNOTATION_TYPE can be used as meta-annotations" and just leave it at
>>>> that.
>>>>
>>>> Without something like "@Metatype" that model doesn't become recursive,
>>>> but maybe that's good enough. The "@Metatype" concept is a simple statement
>>>> of "carry these annotations forward". A simple and explicit statement of
>>>> how far you want the recursion to go.
>>>>
>>>> So here is an exploration of how meta-annotations (annotation reuse)
>>>> could be applied to EJB:
>>>>
>>>>
>>>> https://github.com/dblevins/metatypes/tree/master/metatype-ejb/src/main/java/javax/ejb/meta
>>>>
>>>> The above is a list of "built-in" meta-annotations we might consider
>>>> delivering out of the box. I've put them in a theoretical "javax.ejb.meta"
>>>> package to make it clear that all the annotations there are simply
>>>> repackaged versions of the actual annotations.
>>>>
>>>> Plummed this into a patched version of CXF's JAX-RS support and it's
>>>> proving to be quite fun there as well:
>>>>
>>>> @GET
>>>> @Path("/customers/{id}/")
>>>> public Customer getCustomer(@Id String id) {
>>>> }
>>>>
>>>> The applicability to other specs is that part that gives me most pause.
>>>> It certainly belies the need for a more generic form of annotation reuse
>>>> that isn't specific to a domain like EJB, CDI, Bean Validation, etc. We
>>>> keep creating domain-specific annotations to drive this form of recursion or
>>>> reuse and really we just need one for the whole language.
>>>>
>>>> It's interesting and fun, but perhaps too young for inclusion. Or not.
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>
>>
>>