Type annotations and this-reference (receiver) in methods

[André Pankraz]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20140218/6f61b47f/attachment.html