Bug in encoding type annotations for supertype_targets

[Joel Borggrén-Franck]

Hi Alex,

Actually I suspect the target_info is correct, a supertype_target with
a supertype_index of 65535 for the class cases but read into a signed
char, and 0 for the 0:th interface. This isn't the type_index entry
later in type_annotation structure, Javap just has a non-standard
notation (another bug perhaps?)

Created: https://bugs.openjdk.java.net/browse/JDK-8148504

cheers
/Joel

On Thu, Jan 28, 2016 at 8:35 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> Hi Joel,
>
> On 1/28/2016 10:45 AM, Joel Borggrén-Franck wrote:
>>
>> While working on the core reflection code for type annotation I
>> discovered what I believe is a javac bug. It looks like javac omits
>> the type_path structure for nested types in supertype and implemets
>> targets. In the example below, when looking at GenericSub in javap I
>> get this encoding of @Foo:
>>
>> RuntimeVisibleTypeAnnotations:
>>    0: #18(): CLASS_EXTENDS, type_index=-1, location=[TYPE_ARGUMENT(0)]
>>
>> as expected, but when looking at either Impl or SubInner I get:
>>
>> RuntimeVisibleTypeAnnotations:
>>    0: #15(): CLASS_EXTENDS, type_index=0
>>
>> or
>>
>> RuntimeVisibleTypeAnnotations:
>>    0: #14(): CLASS_EXTENDS, type_index=-1
>>
>> Note the missing type_path (location in javap) for the nesting, which
>> I think table Table 4.7.20.2-E in the vm spec implies.
>>
>> I can file a bug if you want me to.
>
>
> I agree that the "Outer . @Foo Inner"-style terms are legal, and should have
> a target_path item generated.
>
> To be precise, the supertype_target item belongs to the target_info item,
> not the target_path item. supertype_target encodes which type is of interest
> among the one or more types specified after 'extends'/'implements'. All your
> sample programs have exactly one type in their 'extends'/'implements'
> clauses, so I'd be fairly confident that supertype_target is correct. What
> is more likely to be wrong is (as you say) the target_path item which
> encodes the "structural" location of a type annotation within a
> nested/parameterized/array type.
>
> The type_index items are surprising too. type_index is not about the
> location of a type annotation, but about the annotation itself ("@Foo"). It
> encodes the constant pool entry which gives the annotation's own type. 0 and
> -1 are bad answers for that. I suspect javap is actually finding target_path
> items (possibly ill-formed) and showing them as type_index.
>
> So yes, please file a bug.
>
> Alex
>
>
>> cheers
>> /Joel
>>
>> --- 8< ---
>>
>> import java.lang.annotation.*;
>> import java.util.*;
>> import java.lang.reflect.*;
>>
>> /*
>>   * @test
>>   */
>> public class LostTypePath {}
>>
>> class Super {}
>> class Sub extends @Foo Super {}
>>
>> class Generic<A> {}
>> class GenericSub<B> extends Generic<@Foo B> {}
>>
>> class Outer { public static class Inner {}}
>> class SubInner extends Outer . @Foo Inner {}
>>
>> interface IOuter { public interface IInner {}}
>> class Impl implements IOuter . @Foo IInner {}
>>
>> @Target(ElementType.TYPE_USE)
>> @Retention(RetentionPolicy.RUNTIME)
>> @interface Foo {}
>>
>