spec clarification: type annotations on static nested types
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>
>> 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 184.108.40.206 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 220.127.116.11 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 . The draft
section on type_path mentions it distinguishes among locations where "an
annotation may appear" , which as defined doesn't include qualifiers of
I see at least two options to reconcile the JVMS, javac, and core
(a) Update JVMS 18.104.22.168 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
* 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...
More information about the compiler-dev