Record attribute binary format

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Sat Oct 12 20:47:07 UTC 2019


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.

Maurizio

>
>
>> Ugh, I don't think so. Varargs is a method concept; record components 
>> are a bit ephemeral, yes, but they are definitively _not_ methods.
>>
>> Maurizio
>
> Vicente
>
> [1] 
> http://hg.openjdk.java.net/amber/amber/file/df5e1c317777/src/java.base/share/classes/java/lang/reflect/RecordComponent.java#l209
>
>>
>>
>>>
>>> and if we take a look to the past, we have added access flags to 
>>> methods, fields and classes, so there is a non negligible chance 
>>> that we will want to do the same to record components in the future.
>>>
>>> Rémi
>>>
>>>> On 10/11/2019 4:43 PM, Remi Forax wrote:
>>>>> It seems we have to add an access_flag for each record component 
>>>>> because we have
>>>>> to mark if the record component is a varargs or not.
>>>>>
>>>>> So the format should be
>>>>>
>>>>> Record_attribute {
>>>>>     u2 attribute_name_index;
>>>>>     u4 attribute_length;
>>>>>     u2 number_of_record_components;
>>>>>     {   u2 component_access_flags;
>>>>>         u2 component_name_index;
>>>>>         u2 component_descriptor_index;
>>>>>         u2 attribute_count;
>>>>>         attribute_info attributes[attributes_count];
>>>>>     }
>>>>> }
>>>>>
>>>>> with the component_access_flags allowing ACC_VARARGS.
>>>>>
>>>>> Rémi
>


More information about the amber-spec-experts mailing list