JDK 14 record type representation in classfile format?
forax at univ-mlv.fr
forax at univ-mlv.fr
Sat Mar 28 10:24:12 UTC 2020
> De: "Luke Hutchison" <luke.hutch at gmail.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-dev"
> <amber-dev at openjdk.java.net>, "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Samedi 28 Mars 2020 01:06:12
> Objet: Re: JDK 14 record type representation in classfile format?
>> There is a good reason to duplicate the metadata declared at declaration site at
>> callsite, it means that you can avoid to load the class containing the
>> metadata. Here the compiler can find the classfile of the inner class without
>> finding/loading the outer class.
> But as I mentioned, this information is present as an attribute in Lookup (the
> inner class), not just in MethodHandle (the outer class). Therefore you can
> determine the outer class without loading the outer class. In fact it has to be
> that way, because you can't load the outer class before you know what the outer
> class is.
> Furthermore if you don't need to load the inner class, there's no reason why you
> would need to determine the outer class. So if the inner class is actually
> being used, you already have the outer class information, because the inner
> class has already been loaded.
Nope, the trick is to neither load the outer class nor load the inner class.
Let say you have a code that call a method m of a class A, with A seen as a classfile and not as a sourcefile by the compiler.
class A {
void m(MethodHandles.Lookup l) { ... }
}
...
A a = ...
a.m(lookup);
The signature of A::m is (Ljava/lang/invoke/MethodHandle$Lookup;)V but for javac, the variable "lookup" is typed as a MethodHandles.Lookup, so you need to have something that say that java/lang/invoke/MethodHandle$Lookup is MethodHandles.Lookup, this is exactly what you get by adding the attribute InnerClass inside the class A. As you see, you don't need to load MethodHandles or Lookup for get that piece of information.
Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200328/c42460ca/attachment-0001.htm>
More information about the compiler-dev
mailing list