Annotation cycles

[Brian Goetz]

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/
>>>
>>> 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
>>>
>>>
>>
>>
>