Annotation cycles

[Bruce Chapman]

Not so much "unstable equilibrium" as "immature atrophy".

There are several needs and use cases where the current specification 
forces you down such an ugly torturous design path that it is really 
better to not go there. The ones that pain me have relatively simple 
solutions which I don't think could be considered destabilising.

I suspect that the real problem is that these various requested 
improvements to the annotation feature are language changes but each in 
and of themselves is so seemingly minor that it doesn't appear to 
justify the hoop jumping required.

Maybe we need a JEP (or preJEP collaboration) to gather these use cases 
and investigate language changes that can address the majority of these 
pain points.

Bruce


On 18/04/2012 2:39 p.m., Brian Goetz 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/
>>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>
>