spec clarification: type annotations on static nested types

Liam Miller-Cushon cushon at google.com
Mon Jan 22 21:30:04 UTC 2018


I double-checked that the type paths in the class file javac emits are:

  void f(@A One x) {}
...
type_path_length 1
type path entry [0]: type_path_kind: 1, type_path_index: 0

  void g(@A Two x) {}
...
type_path_length 0

My understanding is still that javac uses type_path_kind=1 to step in to
(non-static) inner classes, and reflection interprets type_path_kind=1 as
stepping in to member classes (both non-static and static).
Is this a javac bug, or a reflection bug, or am I confused?

Thanks,

On Mon, Jan 8, 2018 at 2:25 PM, Liam Miller-Cushon <cushon at google.com>
wrote:

> Thanks! I have some follow-up questions inline -
>
> On Mon, Jan 8, 2018 at 12:42 PM, Alex Buckley <alex.buckley at oracle.com>
> wrote:
>
>> A type annotation can apply to a type that's nested (i.e. deeper) in a
>> *static* type though. Adapting an example from JLS 9.7.4:
>> ...
>
> In the second case, the nested type which is being annotated is "C . D".
>> The D part denotes a non-static nested type, yes, but the first type that
>> we hit when stepping through the path -- C -- is static. The storage of
>> @Foo thus involves a type_path that descends "deeper in a nested type" --
>> mentioning anything about static here would be wrong. As a separate issue,
>> the location where we ultimately find @Foo is, in fact, a non-static member
>> type, so javap helpfully shows that location as INNER_TYPE:
>>
>
> I didn't express what I was thinking, sorry. I agree we're not interested
> in the static-ness of the outer type.
>
> I think javac currently emits type_path_kind=1 steps only when descending
> in to a member type that is non-static, and that the
> "location=[INNER_TYPE]" bit of javap's output corresponds directly to the
> type_path structure in the class file.
>
> Is that accurate, and if so is it to spec?
>
> My understanding of the `@Foo C . D x;` example was that no type_path is
> necessary even though C is a member of Test, because C is a static member
> and Test is 'scoping construct' that is not a valid type annotation target.
>
> I don't like how @A has been bounced out of the nested type "T . Two" so
>> that it allegedly applies to the type of the formal parameter as a whole.
>> @A actually applies to the type of the static member Two that is declared
>> by T.
>>
>
> Similar to the other example, isn't "@A actually applies to the type of
> the static member Two" the only interpretation for a type annotation
> attribute that applies to `T . Two`, since T is a scoping construct and is
> not a valid type annotation target?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180122/7a785f6b/attachment-0001.html>


More information about the compiler-dev mailing list