spec clarification: type annotations on static nested types

[Liam Miller-Cushon]

On Thu, Feb 22, 2018 at 11:23 AM Liam Miller-Cushon <cushon at google.com>
wrote:

> On Wed, Feb 21, 2018 at 2:43 PM, Alex Buckley <alex.buckley at oracle.com>
> wrote:
>
>> On 2/21/2018 2:34 PM, Liam Miller-Cushon wrote:
>>
>>> I'm now reading "nested type" as meaning a type that is nested inside an
>>> *annotatable* type.
>>> i.e. in A.B where B is a non-static inner class, A is an annotatable
>>> enclosing instance type, so a type path is needed to indicate that in
>>> `A. at Foo B` the annotation is on B.
>>> However in A.B where B is a static member class, A is a 'scoping
>>> construct' rather than an annotatable type, so no type path is needed
>>> for `A. at Foo B` since B is the only annotatable type.
>>>
>>
>> That sounds plausible -- the "scoping construct" concept tunneled itself
>> fairly deeply into the JLS -- but I don't especially recall that "nested
>> type" in JVMS 4.7.20.2 meant to represent only non-static members. I can
>> only suggest more digging on type-annotations-spec-experts, sorry.
>
>
>From some offline discussion with Mike and Werner, the original intent was
for "nested type" in JVMS 4.7.20.2 to only apply to non-static members.

I couldn't find related discussions in type-annotations-spec-experts.
However there's some language in the jsr308 draft about locations where
type annotations may appear, which mentions 'scoping mechanisms' and which
rules out annotations on qualifiers of static members [1]. The draft
section on type_path mentions it distinguishes among locations where "an
annotation may appear" [2], which as defined doesn't include qualifiers of
static members.

I see at least two options to reconcile the JVMS, javac, and core
reflection.

(a) Update JVMS 4.7.20.2 to mention non-static members, update core
reflection to match, and leave javac's current behaviour as-is.
(b) Change javac's behaviour to emit type path entries for both static and
non-static member classes.

I think there are a couple of reasons to prefer (a).
* It results in slightly more efficient class files, with more compact
type_path structures.
* it avoids breaking compatibility with the code javac and ecj have been
generating since JDK 8. Changing getAnnotatedOwnerType seems lower-risk
since it was added more recently, and (due to the issue we're discussing)
doesn't work reliably.

[1]
https://checkerframework.org/jsr308/specification/java-annotation-design.html#type-names
[2]
https://checkerframework.org/jsr308/specification/java-annotation-design.html#class-file%3Aext%3Atype_path
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181119/db6b99fd/attachment.html>