(original) (raw)

On Thu, Feb 22, 2018 at 11:23 AM Liam Miller-Cushon <cushon@google.com> wrote:
On Wed, Feb 21, 2018 at 2:43 PM, Alex Buckley <alex.buckley@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.@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.@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.