I think we need to sort this all out very slowly...
Pete Muir wrote:
> 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,
Isn't an annotation with an ANNOTATION_TYPE target type, a
meta-annotation by default? In David's example @Metatype seems to be a
marker for the derived annotations (for easier processing?)
> 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.
>
Do you mean their derived annotations (like @Yearly in David's example)?
Another question: would we expect CDI to be responsible for processing
those derived (@Metatype ?) annotations? Or would all other containers
need to process them even if CDI is not enabled?
thanks,
-marina
> 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
>>>>>
>>>>>
>>>>>
>>>
>>>