JDK 14 record type representation in classfile format?

[forax at univ-mlv.fr]

> 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é: Vendredi 27 Mars 2020 19:19:09
> Objet: Re: JDK 14 record type representation in classfile format?

> On Sun, Mar 22, 2020 at 10:06 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> To me, it seems to be needed for the separate compilation,
>> when javac reads the type of a class members that contains a '$', it has no idea
>> if it's an inner class or not,
>> the attributes InnerClasses is there to disambiguate.

> But the java.lang.invoke.MethodHandles$Lookup class itself contains an
> InnerClasses attribute with the mapping of innerClass =
> "java.lang.invoke.MethodHandles$Lookup", outerClass =
> "java.lang.invoke.MethodHandles". So the JRE can resolve this by looking at the
> Lookup itself, which logically should be the intent.

It's not the JRE, it's the compiler. 
Rewording what you are saying, "the InnerClass attribute is also present at declaration site, so there is no need to have it at use site". 

> I don't see why this information would need to be duplicated in every class that
> needs access to the Lookup class due to the use of bootstrap methods. That does
> not seem right to me

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. 

cheers, 
Rémi