RFR: JEP 359-Records: reflection code

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>, "compiler-dev"
> <compiler-dev at openjdk.java.net>, "Chris Hegarty" <chris.hegarty at oracle.com>
> Envoyé: Mardi 22 Octobre 2019 18:34:13
> Objet: Re: RFR: JEP 359-Records: reflection code

> I think there’s something in between “specific to records” and “general building
> block”.

> It definitely, 100% was intended to NOT be specific to records. But, it is still
> not general, in the sense that no human user will ever call this API. So it is
> (or should be) optimized for what makes sense from a runtime performance /
> class file impact perspective. 100% of the clients of this API will be
> compilers and frameworks. It may well be used by Javac for value types, and
> could be used by other language compilers as well. So that’s the target profile
> we’re aiming at.

With my language runtime dev hat, the way to find the getters is language dependent, so it makes sense to have an API with 3 entrypoints which is based on getters for equals/hashCode or getters + string format for toString but for records but at the same time from the class format perspective it makes little sense to send the getters for a record so it's better to use another entry point. 

I like Maurizio's idea to separate the API in: 
- 3 reusable entry points: 
defaultObjectEquals(getters), defaultObjectHashCode(getters), defaultObjectToString(getters + stringconcat format) that are public method handles that returns MethodHandle 
- 1 boostrap method for records 
recordObjectMethodsBootstrap(Lookup lookup, String methodName, MethodType type) that uses reflection to create the getters and delegate to the methods above 

For inline types, we will add a new boostrap method inlineObjectMethodsBootstrap that may use different parameters. 
For other languages, unlike the lambdaMetaFactory that spins bytecode so restrict which kind of method refs can be used, here all methods defaultObject*() are directly reusable so a language like Groovy which is bean based can use the Introspector to find all the properties and then use methods defaultObject*(). 

My idea of using a constant dynamic in the middle is an optimization that can be done later because records are released has a preview feature we can still change the bytecode encoding in the next release. 

Rémi 

>> On Oct 22, 2019, at 6:01 AM, Maurizio Cimadamore < [
>> mailto:maurizio.cimadamore at oracle.com | maurizio.cimadamore at oracle.com ] >
>> wrote:

>> But, if this is meant to be a general building block, then I don't understand
>> e.g. why we are unifying all the signatures. If a client wants hashCode, I
>> think it is kind of a design flaw that (i) there's no such BSM with that name
>> (the BSM is just called "bootstrap") and (ii) that there still a requirement to
>> pass a 'name list', which is ignored by the BSM.