Request for comments: type annotations on nested types

[Werner Dietl]

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
>>
>



-- 
http://www.google.com/profiles/wdietl