Record attribute binary format

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Vicente Romero" <vicente.romero at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>, "Brian Goetz"
> <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Samedi 12 Octobre 2019 22:47:07
> Objet: Re: Record attribute binary format

> On 12/10/2019 02:36, Vicente Romero wrote:
>>
>>
>> On 10/11/19 6:50 PM, Maurizio Cimadamore wrote:
>>>
>>> On 11/10/2019 22:19, forax at univ-mlv.fr wrote:
>>>> ----- Mail original -----
>>>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>>>> À: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
>>>>> <amber-spec-experts at openjdk.java.net>
>>>>> Envoyé: Vendredi 11 Octobre 2019 22:57:23
>>>>> Objet: Re: Record attribute binary format
>>>>> No need.  Varargs-ness is reified with the (mandated) canonical ctor.
>>>> hum, this looks like a hack, it means you can not just read the
>>>> Record attribute, you have to crawle all the methods to find the
>>>> primary constructor.
>>>
>>> It _looks_ like an hack, but I think that, after some more thinking
>>> it's actually more correct than what you are proposing. A record
>>> contains a bunch of components, the components have a name and a
>>> type. Vararg-ness  is immaterial here; both
>>>
>>> record Foo(Object[] arr) { ... }
>>>
>>> and
>>>
>>> record Bar(Object... arr) { ... }
>>>
>>> Denote the same underlying state (e.g. an Object array). The only
>>> difference between Foo and Bar is that their _construction protocol_
>>> is different (which might also mean, in the future, that Bar will get
>>> more liberal _deconstruction_ protocols too!); but this is cleanly
>>> captured in the canonical constructor method_info.
>>>
>>> Pedagolical test: would an 'isVarargs()' predicate on the core
>>> reflection record component be acceptable?
>>
>> that method as already added to j.l.r.RecordComponent, see [1],
> 
> The link is not working ATM, but in any case, I don't think I like that
> too much. This will return false always, except for, in some cases, the
> last record component.
> 
> It's not a single method _parameter_ that is varargs. It's the whole method.
> 
> In the same way, I think that reasoning of a single record component as
> 'varargs' is a red herring.


Ok, i change my mind on this :)
I agree with you that currently we only have varargs methods/constructors, there is no varargs parameters.

So a "..." on the type of the last record component means that the record itself is a varargs not that a peculiar record component is a varargs.

But technically a varargs record only means that when constructing a record, the canonical constructor is a varargs.

So the method isVarargs() should be removed from the java.lang.reflect.RecordComponent.


BTW, Should java.lang.Class have a method getCanonicalRecordConstructor() ?

BTW2, if in the future we need some access flags on record components, we can still add a new attribute like MethodParameters on the Record attribute, so the current binary format is Ok.

> 
> Maurizio

Rémi