The Record Attribute - What does it mean to be a record at runtime?

[Chris Hegarty]

> On 13 Nov 2020, at 10:15, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "daniel smith" <daniel.smith at oracle.com>, "Chris Hegarty" <chris.hegarty at oracle.com>, "amber-spec-experts"
>> <amber-spec-experts at openjdk.java.net>
>> Envoyé: Vendredi 13 Novembre 2020 01:18:01
>> Objet: Re: The Record Attribute - What does it mean to be a record at runtime?
> 
>>> ...
> 
> I fully agree that the codes in Field.set(), lookup.findSetter/unreflectFiedl() have to be fixed,

We seem to have arrived at a common understanding that there is at least a problem to be fixed - good ;-)

> i disagree that this is a problem related to records.

When the Hotspot VM was changed to trust non-static final fields in “records” [1], there was only one notion of what that meant - it was the full JLS definition of a record class (since the Hotspot VM would throw CFE for classes with the record attribute while not extending j.l.Record, or non-final). The Hotspot VM implementation subsequently changed [2]. Given that the landscape has changed, it seems right and proper to revisit the decision to trust non-static final fields in “records” - or, at least, the set of circumstances upon which to base that trust.

I will add an additional piece of information that I realise hasn’t come up yet. I added the check for “direct superclass is j.l.Record” to Class::isRecord because of a discomfort that arose during one of the records CSR’s (details not to hand), since the JVMS does no include such. At the time, given the Hotspot VM implementation, this was the minimum acceptable solution that we arrived at, so as to keep the Hotspot VM and other parts of the runtime in agreement.

> For enums, the VM and the reflection disagree about what an enum is, and that's not an issue.
> (in fact, isEnum() et getEnumConstants() also disagree of what an enum is).

I respectfully disagree, but there is likely nothing to be gained by trashing this out here, other than to say that I don’t accept this in any way as precedent, or good design to follow.

> The fact that there is no record access bit in the header of a class is to avoid to use one of these precious bits.
> So from the VM POV, a class is a record because it has the Record attribute.

Well, as discussion progresses, this seems to be crux upon which the discussion hinges - which is where I started :-)

> As i told Chris, i believe that the best to fix this issue is to have the VM to export a method boolean hasWeakFinalFieldSemantics(Class) that says if a class allows final fields to be set or not.
> And to fix the spec of Field.set(), lookup.findSetter/unreflectFiedl() to say that only plain old classes and enums allow their final fields to be set.

You did say this, but I did not ( and still do not ) accept that this is the right way to solve the problem.

>> ..
>> (*) Field::set doesn't fail when Class::isRecord returns true (which is
>> what we currently specify) but when the class the field belongs to has
>> the Record attribute. Should we add that to the javadoc ?
> 
> that only POJO and enums final fields can be set.

That is not a reasonable assertion to make in the Java SE Specification.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8247444
[2] https://bugs.openjdk.java.net/browse/JDK-8255342


> Rémi
> 
>> 
>>> 
>>> With that, the JLS definition of a record doesn't need to leak into the JVMS.
>>> 
>>>> Maurizio
>>> Rémi
>>> 
>>>> On 11/11/2020 02:39, Dan Smith wrote:
>>>>>> On Nov 10, 2020, at 1:51 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>>>> 
>>>>>> My issue is with how the VM determines whether a field is trusted or not. The VM
>>>>>> trusts fields in (among other types) “record” classes. So what is a record
>>>>>> class to the VM?   (that is the question that I am trying to resolve) - the
>>>>>> answer is not in the JVMS ( which is fine ).
>>>>> Suggestion: the VM shouldn't bother to provide any definition for "record
>>>>> class". That's up to Java language compilers and reflection (which should be in
>>>>> agreement).
>>>>> 
>>>>> Instead, can't we say the VM trusts fields in classes that have a Record
>>>>> attribute? Who cares whether those classes are "real" records or not? (I may be
>>>>> missing something because I don't fully understand the concept of "trusted
>>>>> final field", but it seems to me like HotSpot has a lot of freedom to decide to
>>>>> trust or not trust whatever fields it wants.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201113/d5e5e74f/attachment.htm>