RetentionPolicy.CLASS too broad for TYPE_USE annotations ?

Alex Buckley alex.buckley at
Tue Oct 15 15:57:01 PDT 2013

Markus raised some great points on the type-annotations-spec-observers 
list, in regard to the draft JLS/JVMS updates for 308.

On 10/15/2013 1:10 PM, Markus Keller wrote:
> Could you please have a look at these? Shouldn't be too late for that.

1. The name of a receiver parameter in the draft is allowed to be 'this' 
or the text of a qualified expression indicating the same class. I 
raised this issue with the EG on April 10 ("Clarifying the receiver 
parameter") because the 308 design document gave only an example. 
Srikanth asked for rationale; I gave it. No-one else commented despite 
my best efforts to highlight the semi-open thread at later dates.

2. I take your point about the draft grammar. This has been discussed 
over the years, and my natural tendency towards a simple recursive 
production ("Type {Annotation} []") is not in fact what was settled on. 
I will change ArrayType to align with section 2.2 in the 308 design 
document, where "{Annotation} []" can repeat after a non-array type. I 
will also clarify the precise type in an array type to which an 
annotation applies.


1. I have corrected the "Where Types Are Used" paragraph to acknowledge 
primitive types. This is normative but non-testable text, i.e. a sketch, 
so it doesn't have to mention array types although it could do so as the 
308 spec settles in the JLS at a later date.

2. The places where 'void' is mentioned in the 308 design document are:

The grammar permits modifiers, declaration annotations, and type 
annotation to be freely intermixed at any location where all are 
permitted (such as before a field declaration or a non-void-returning 

@MAnno void myMethod1() { ... } // legal, one method annotation
@TAnno void myMethod2() { ... } // illegal
@MTAnno void myMethod3() { ... } // legal, one method annotation

The clear intent is that 'void', not being a type, cannot be preceded by 
a TYPE_USE annotation. I will make it a compile-time error if this 
happens in a method declaration.


More information about the type-annotations-spec-experts mailing list