Type annotations clarification
Alex Buckley
alex.buckley at oracle.com
Mon Feb 24 13:20:06 PST 2014
Right.
Now, if class Inner<T> is declared static (i.e. it's still a nested
class, but not an inner class), then the INNER_TYPE path disappears. "@C
Inner<@D String> f2" compiles to:
Outer$Inner<java.lang.String> f2;
descriptor: LOuter$Inner;
flags:
Signature: #10 // LOuter$Inner<Ljava/lang/String;>;
RuntimeInvisibleTypeAnnotations:
0: #12(): FIELD, location=[TYPE_ARGUMENT(0)]
1: #12(): FIELD
because Outer is now a "scoping mechanism" for Inner, much like a
package name would be, so it's not part of the annotated type per se.
Alex
On 2/24/2014 1:01 PM, Werner Dietl wrote:
> I think @C and @D need to have the same type path as @A and @B.
> In the compiled bytecode, the signature for both fields is the same.
> The output of javap for the example looks correct to me:
>
> Outer$Inner<java.lang.Integer> f1;
> descriptor: LOuter$Inner;
> flags:
> Signature: #10 // LOuter$Inner<Ljava/lang/Integer;>;
> RuntimeInvisibleTypeAnnotations:
> 0: #12(): FIELD, location=[INNER_TYPE]
> 1: #13(): FIELD, location=[INNER_TYPE, TYPE_ARGUMENT(0)]
>
> Outer$Inner<java.lang.String> f2;
> descriptor: LOuter$Inner;
> flags:
> Signature: #15 // LOuter$Inner<Ljava/lang/String;>;
> RuntimeInvisibleTypeAnnotations:
> 0: #16(): FIELD, location=[INNER_TYPE, TYPE_ARGUMENT(0)]
> 1: #17(): FIELD, location=[INNER_TYPE]
>
> If @C and @D used a different type path, the type annotations couldn't
> be correctly matched.
>
> cu, WMD.
>
>
> On 02/24/2014 03:53 PM, Eric McCorkle wrote:
>> I need a brief clarification on what the type path should look like for
>> some type annotations.
>>
>> In the following example:
>>
>>
>> class Outer {
>>
>> class Inner<T> {}
>>
>> Outer. at A Inner<@B Integer> f1;
>>
>> @C Inner<@D String> f2;
>>
>> }
>>
>>
>> The type paths for @A and @B look like this:
>>
>> @A: [INNER_TYPE]
>> @B: [INNER_TYPE, TYPE_ARGUMENT(0)]
>>
>> The question is, what about @C and @D, which are on an unqualified
>> reference to Inner? Should they be the same as for @A and @B, or should
>> they look like this:
>>
>> @C: []
>> @D: [TYPE_ARGUMENT(0)]
>>
>>
>>
>> Thanks,
>> Eric
>>
More information about the compiler-dev
mailing list