Request for comments: type annotations on nested types
alex.buckley at oracle.com
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.
> CantAnnotateStaticClass.java 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