Request for comments: type annotations on nested types

[Alex Buckley]

Given:

class Top {
   static class Outer {
     class Inner {}
     static class SInner {}
     interface IInner {}
   }
}

I realized that the draft 308 JLS was not in agreement with:

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

Each of these is a local variable declaration that provides a "type 
context" where a type is used. This makes sense if you consider that the 
LocalVariableDeclaration production uses Type, not TypeName. The spec 
allows @TB in all the positions shown above. However, we want to say 
that parts of a nested type may not be annotated if the type overall 
refers to a static member. I need to add that in the draft.

(This is different than a field access like "Outer.SInner.f". The 
locations where it can appear are not deemed to be type contexts, so no 
part of the TypeName "Outer.SInner" can be annotated by TYPE_USE 
annotations.)

Alex

On 6/18/2013 3:55 PM, Werner Dietl wrote:
> Thanks for these comments, Alex.
>
> In the language model, there is no TypeMirror for some of these, so
> you would have a TYPE_USE annotation according to the bytecode which
> is not represented in the language model.
> (I found javac inconsistent in when Outer had a Type and when not.
> I'll write up a small test case and send that out separately.)
>
> I will not push my updates until the EG decided the desired behavior.
>
> Failing tests T8008762.java and TestAnonInnerClasses.java are waiting
> on this discussion:
> http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-April/000782.html
>
> There are some refactorings of the Annotations code in the pipeline
> and I suggest we look at these issues again after those refactorings.
>
> cu, WMD.
>
> On Mon, Jun 17, 2013 at 12:57 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
>> // 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.
>>
>> Alex
>>
>>
>> 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.
>>>
>>> --
>>> http://www.google.com/profiles/wdietl
>>>
>>
>
>
>