Type annotations and this-reference (receiver) in methods

[Werner Dietl]

Hi André,

I'm not sure what you mean with "move ... into TestS" and INNER paths
missing for that case.
I've modified the example by putting the test method in all three
classes. I get consistent type annotations in all cases.
Can you specifically point out what type paths are missing?

Thanks,
cu, WMD.


On Tue, Feb 18, 2014 at 1:54 AM, André Pankraz <andre at pankraz.de> wrote:
> Hi,
>
> thank you for looking into it. I tested your example, in this case all is
> OK.
> If you now move the testInnerGenericHandled() into TestS, then the INNER
> path will be missing for the first reference.
>
>       #32 @org.decojer.cavaj.test.jdk8.Lambda.TA(
>
>         target type = 0x45 CONSTRUCTOR_REFERENCE
>         offset = 0
>       )
>       #35 @org.decojer.cavaj.test.jdk8.Lambda.TB(
>
>         target type = 0x45 CONSTRUCTOR_REFERENCE
>         offset = 0
>         location = [TYPE_ARGUMENT(0)]
>       )
>       #38 @org.decojer.cavaj.test.jdk8.Lambda.TC(
>         target type = 0x4a CONSTRUCTOR_REFERENCE_TYPE_ARGUMENT
>         offset = 0
>         type argument index = 0
>       )
>
> May be it's intentional? I could imagine some rule here...same inner class
> context etc., but then I would like to have the spec hint for this?
>
> In each case: it isn't similar to the also existend problem that type
> annotations for construcutors with artificial enclosing references have the
> wrong offset, if this was the pointed out similarity by Alex to a known bug.
>
>
> Regarding a) from Alex:
>
> Buw how will anyone use information that is incomplete? I specificely point
> out that this is _runtime_-information...so someone should be able to do
> something with it at runtime. If you have a type path that references type
> arguments in local variables - without the signature information for local
> variables (that happens to be in debug info), then this information is
> useless? I havn't completely understood this.
>
> I also don't know how much all-encompassing reference Type Checker can be
> for such runtime information cases, if such fundamental stuff like runtime
> info operation offsets where entirely wrong. Haven't really used it yet.
>
> Cheers,
> André
>
>
> 2014-02-17 20:25 GMT+01:00 Werner Dietl <wdietl at gmail.com>:
>
>> Hi André, Alex,
>>
>> >> 2)
>> >> If you look into the following code, then I think the Method Reference
>> >> Type Annotations are missing the INNER path.
>> >> Focus onto first line testInnerGenericHandles().
>> >>
>> >>
>> >> public class DecTestMethodHandles {
>> >>
>> >>      static class Test<S> extends DecTestMethodHandles {
>> >>
>> >>          public static <T> void testStatic() {
>> >>              System.out.println("test");
>> >>          }
>> >>
>> >>          public <T> Test() {
>> >>              System.out.println("new...");
>> >>          }
>> >>
>> >>          public <T> void test() {
>> >>              System.out.println("test");
>> >>          }
>> >>
>> >>          void testInnerGenericHandles() {
>> >>              Runnable r = @Nonnull Test<@Nonnull String>::<@Nonnull
>> >> Integer> new;
>> >>              r = @Nonnull Test::<@Nonnull Integer> testStatic;
>> >>              r = new @Nonnull Test<@Nonnull String>()::<@Nonnull
>> >> Integer> test;
>> >>              r = super::<@Nonnull String> testSimpleHandles;
>> >>          }
>> >> ...
>> >>      }
>> >>
>> >>
>> >> You get this attribute in testInnerGenericHandles():
>> >>
>> >>      RuntimeVisibleTypeAnnotations:
>> >>        #34 @org.decojer.cavaj.test.jdk8.Nonnull(
>> >>          target type = 0x45 CONSTRUCTOR_REFERENCE
>> >>          offset = 0
>> >>        )
>> >>
>> >> There is no INNER path in this. According to the order how this is
>> >> encoded in bytecode, this bytecode presents "@Nonnull
>> >> DecTestMethodHandle.Test::new" and not "DecTestMethodHandle. at Nonnull
>> >> Test::new" (or shorter "@Nonnull Test::new")
>> >> Haven't tested it the type argument has same issues.
>> >>
>> >> May be I understood the spec wrong here and here isn't a inner type
>> >> path
>> >> necessary. It's the same topic like previous thread about INNER pathes.
>> >
>> > This feels pretty close to the known bug in attribute generation for
>> > annotations on nested types.
>>
>> I don't think there is a problem here. Take this expanded example:
>>
>> import java.lang.annotation.*;
>>
>> class Lambda {
>>
>>     static class TestS<S> {
>>         public <T> TestS() {
>>             System.out.println("newS...");
>>         }
>>     }
>>     class TestI<S> {
>>         public <T> TestI() {
>>             System.out.println("newI...");
>>         }
>>     }
>>
>>     void testInnerGenericHandles() {
>>         Runnable r = @TA TestS<@TB String>::<@TC Integer> new;
>>         r = @TA TestI<@TB String>::<@TC Integer> new;
>>     }
>>
>>     @Target(ElementType.TYPE_USE)
>>     @interface TA {}
>>     @Target(ElementType.TYPE_USE)
>>     @interface TB {}
>>     @Target(ElementType.TYPE_USE)
>>     @interface TC {}
>> }
>>
>>
>> Method testInnerGenericHandles has the following type annotations:
>>
>> RuntimeInvisibleTypeAnnotations:
>>  0: #23(): CONSTRUCTOR_REFERENCE, offset=0
>>  1: #24(): CONSTRUCTOR_REFERENCE, offset=0, location=[TYPE_ARGUMENT(0)]
>>  2: #25(): CONSTRUCTOR_REFERENCE_TYPE_ARGUMENT, offset=0, type_index=0
>>  3: #23(): CONSTRUCTOR_REFERENCE, offset=6, location=[INNER_TYPE]
>>  4: #24(): CONSTRUCTOR_REFERENCE, offset=6, location=[INNER_TYPE,
>> TYPE_ARGUMENT(0)]
>>  5: #25(): CONSTRUCTOR_REFERENCE_TYPE_ARGUMENT, offset=6, type_index=0
>>
>> Where #23, #24, and #25 correspond to TA, TB, and TC, respectively.
>> With the static inner class, the outer class is only a scoping construct
>> and no INNER_TYPE is required in the location path.
>>
>> Does this sound correct?
>> cu, WMD.
>
>



-- 
http://www.google.com/profiles/wdietl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lambda.java
Type: text/x-java
Size: 985 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20140219/63710535/Lambda.java