spec clarification: type annotations on static nested types

Liam Miller-Cushon cushon at google.com
Tue Nov 20 02:21:37 UTC 2018

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

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

(a) Update JVMS 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181119/db6b99fd/attachment.html>

More information about the compiler-dev mailing list