Request for comments: type annotations on nested types

Alex Buckley alex.buckley at
Mon Jun 17 12:57:54 PDT 2013

// For simplicity, sending solely to type-annotations-dev.

In what follows, I intend to be precise in talking about _names_ rather 
than _types_. I am not even going to say "type use" because without some 
forthcoming JLS changes, it's not precise enough. I am going to speak 
solely about qualified names composed of simple names.

The goal of JSR 308 is that a simple name that acts merely as a "scoping 
mechanism" may not be annotated.

Thus, in a qualified package name like "java.lang", neither the simple 
package name "java" nor the simple package name "lang" may be annotated.

And, in a qualified type name like "A.B", the simple type name "A" may 
not be annotated if the simple type name "B" refers to a static member. 
That is, "A" may not be annotated if the type referred to by "B" does 
not have an enclosing instance.

As I look through the fine scenarios in CantAnnotateStaticClass2 (since 
CantAnnotateStaticClass3 is just a demo that all member declarations in 
an interface are static), javac looks to be applying the rules correctly:

   @TB Outer f1;
   @TB Outer.Inner f1a;
   @TB Outer.SInner f2a; // err
   @TB Outer.IInner f3a; // err

The problem is, it's rather subtle for the language to work like this:

   @TB Outer. @TC Inner f1c;
   @TB Outer. @TC SInner f2c; // err
   @TB Outer. @TC IInner f3c; // err

The ClassFile representation of annotations on qualified type names does 
not care whether the underlying declarations are static. Personally, I 
am inclined to drop the "scoping mechanism" rule and allow a TYPE_USE 
annotation on any simple type name. (I would not, at this stage of the 
JSR, extend such freedom to simple type names in class-oriented 
expressions like class literals and qualified this expressions, because 
storing annotations thereon would require ClassFile changes.) I intend 
to discuss this with the EG when practical.


On 6/16/2013 4:06 PM, Werner Dietl wrote:
> Dear all,
> I've been working on type annotations on nested types and want to make
> sure I'm implementing the right checks.
> Find three test classes attached that should contain all legal
> combinations of nesting of types.
> Instead of a .out file, see "// err" markers for the lines that I expect errors.
> contains only legal combinations; see
> tests 2 and 3 for error cases.
> My interpretation is basically that, if it is possible to refer to a
> "Outer.this" object, it should be possible to have a type annotation
> on that type use.
> Does everybody agree with this interpretation?
> Do you see any errors in my test cases?
> Do you see a way to write the test cases in a more succinct and complete way?
> I have a few local changes that refactor this part of the compiler.
> I'll push once we agree on the checks.
> Thanks for all comments!
> cu, WMD.
> --

More information about the type-annotations-dev mailing list