Annotation cycles

[Debasish Ray Chawdhuri]

I am sorry but I saw neither community nor argument in this topic. Although
it appears that allowing annotation inheritance or all annotations would
not help, but it was not actually discussed in the community why such
feature is desirable. I think we should wait for the original proposers to
come up with some reason why  they think its important or desirable.

In  my opinion, people are thinking about the extensibility of XML and want
to have that in annotations too ramped up with java's features. Say for
example in some API, @Persistent  is an annotation that has a mandatory to
mentions the type as to whether its PersistentType.TABLE or
PersistentType.FILE. A subtype annotation @TablePersistent may override (so
to speak) the type() method to default to TABLE, (or may be we can have a
syntax to make it fixed to TABLE so that it cannot be specified anymore. ).
An API that only understands the @Persistent annotation can now
automatically use the @TablePersistent without any change. This is a simple
example, it would be relevant if @Persistent has a lot of complex
attributes that must be specified. This is just one usecase I can think of,
there can be many others.

On Wed, Apr 18, 2012 at 8:09 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Clearly the community is making a compelling argument that the current
> feature set is in an unstable equilibrium, and adding any more features
> would topple the balance...
>
>
> On 4/17/2012 12:24 PM, Jonathan Gibbons wrote:
>
>> Creeping featurism, guys!
>>
>> -- Jon
>>
>> On 04/17/2012 08:59 AM, David M. Lloyd wrote:
>>
>>> Arrays too?
>>>
>>> On 04/17/2012 10:42 AM, Roel Spilker wrote:
>>>
>>>> And while you're at it, we have another proposal ready to be pushed
>>>> allowing any annotation to be the result of an annotation method:
>>>>
>>>> @interface A {
>>>> Annotation value();
>>>> }
>>>>
>>>> See http://projectlombok.org/**anyannotation/<http://projectlombok.org/anyannotation/>
>>>>
>>>> The required changes to both specs and implementation are very small.
>>>> All the work has bene done already, albeit based on the jdk7 source. the
>>>> only things missing are a JEP, TCK and updating it to the current state
>>>> of JDK8.
>>>>
>>>> Roel
>>>>
>>>> On Tue, Apr 17, 2012 at 2:59 PM, Jesse Glick <jesse.glick at oracle.com
>>>> <mailto:jesse.glick at oracle.com**>> wrote:
>>>>
>>>> On 03/11/2012 06:19 PM, Joe Darcy wrote:
>>>>
>>>> two annotation types cannot be containers for each other because
>>>> that would create an illegal cyclic annotation type situation
>>>>
>>>>
>>>> So long as you are changing the language spec for annotations, why
>>>> not fix this longstanding irritation too (#6264216), which
>>>> arbitrarily prevents a rather wide range of use cases for
>>>> annotations? For example, move the cycle check from declaration time
>>>> to use time, so that the only rejected constructs would be genuinely
>>>> nonterminating cycles that no one would ever intentionally write:
>>>>
>>>> @interface A {
>>>> B[] bs() default {@B};
>>>> }
>>>> @interface B {
>>>> A as() default {@A};
>>>> }
>>>> @A class X {} // oops
>>>>
>>>> but so that legitimate cases compile:
>>>>
>>>> @interface A {
>>>> B[] bs() default {};
>>>> }
>>>> @interface B {
>>>> A[] as() default {};
>>>> }
>>>> @A(@B(@A)) class X {} // fine
>>>>
>>>>
>>>>
>>>
>>>
>>


-- 
Debasish Ray Chawdhuri
http://www.geekyarticles.com/
[A collection of advanced articles on java]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20120418/f3afb4fd/attachment.html