Type annotations on scoping mechanisms and type/declaration annotation errors
alex.buckley at oracle.com
Tue Oct 8 18:01:24 PDT 2013
On 10/7/2013 7:35 PM, Werner Dietl wrote:
> Hi Alex,
>> 1. CantAnnotateStaticClass is still OK and CantAnnotateStaticClass2 still
>> makes me confused. Please see my question to you on
>> type-annotations-spec-observers, after your response to Srikanth on Y.YY.Z.
> Just replied.
> I agree that the test case CASC2 is not the cleanest and would
> appreciate somebody else independently testing the logic I
CantAnnotateStaticClass2.java and CantAnnotateStaticClass3.java would be
clearer if each error line had only one annotation. For example, "@TB
Outer . Inner" is enough to show the error - there's no need for "@TB
Outer . @TC Inner".
What's missing are cases of the form "Top . @TB Outer . ..." - no
annotation on Top. Currently, Top is always annotated and that's always
an error (since Outer is not an inner class) but it means no information
is gained from the many "@TA Top . ..." examples.
>> 2. CantAnnotateScoping.java looks good. FYI the @DA in "java. at DA
>> lang.Object" is illegal because @DA is decorating part of a type in a type
>> context, but DA is not applicable to type contexts.
> Do you agree with the error messages I raise in these examples?
> I also have a "java. at DA XXX.Object" test case and am not quite sure
> how many error messages would be most helpful.
> See the following test case:
> fields f5 and f6.
Just one error message is preferable - because @DA applies to part of a
type in a type context, but DA is not applicable to type contexts.
'lang' should not be classified as a strict TypeName - I presume the
presence of @DA is doing so, but it should not be revealed in an error
More information about the type-annotations-dev