Type annotations and this-reference (receiver) in methods
André Pankraz
andre at pankraz.de
Wed Feb 19 22:54:03 PST 2014
Hi,
checked again in the given variants, this was the deciding hint:
"With the static inner class, the outer class is only a scoping construct
and no INNER_TYPE is required in the location path."
So it's not just dependent if enclosings exist but also if they are no pure
scoping constructs. Then it's OK, I can adapt my type reader thx!
Nevertheless I run into multiple real compiler errors, some of them are
very global and not type annotation related.
public class Lambda {
interface Test {
String hello(String firstname, String lastname);
}
public static void testCapture() {
final String greetings = "Hello";
final String space = " ";
final Test test = (String firstname, String lastname) -> {
return greetings + space + firstname + space + lastname;
};
System.out.println(test.hello("Jim", "Tester"));
}
}
If I then get such bytecode with "-g:none" I'm really afraid for the
overall quality if this is really released in march (I use
jdk-8-fcs-bin-b129-windows-x64-07_feb_2014):
public static void testCapture();
0 aload_0 (what ???)
1 aload_1 (hmmm ???)
I mean this is nearly hello world level. Found also other strange problems
in latest binary release of javac.
I just wait some time and hopefully not to many run into such issues (if
really release in a month) or this might be not the best press about java.
Even though I'm not happy about the bytecode concept for type annotations I
will stop complaining about the tree before the wood and just ignore
unusable (for me) runtime info.
Best regards,
André
2014-02-20 0:12 GMT+01:00 Werner Dietl <wdietl at gmail.com>:
> 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 --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20140220/065143e9/attachment-0001.html
More information about the type-annotations-dev
mailing list