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

[Maurizio Cimadamore]

> For me, you are focusing on the wrong side of the time line,
> trusted final fields should be the new normal and plain old classes are the ones that are weird because they have a *weak* final fields semantics.
>
> So instead of saying that records, hidden classes, anonymous classes (and soon primitive object classes) are special, the VM should say that plain old classes are the outlier.

In an ideal world, yes, although I don't think wishing that does 
anything for our current issue(s) with records.

Btw, for the records, the work described here:

https://bugs.openjdk.java.net/browse/JDK-8233873

iis what's required to enable final field optimization _safely_ (stress 
this word many times, please) for _all_ classes. But that's besides the 
point.

The point in my email is that just attaching an attribute (the record 
attribute) to a class doesn't magically remove the safety concerns 
associated with trusting final fields (some of which are captured in the 
above RFE). With the current mechanism for trusted final fields we still 
have to double check that trusted finals cannot be updated. So there has 
to be a symmetry between the logic granting the trusts and the logic 
which keeps the platform on a safe ground by rejecting final fields updates.

In the current situation, I'm not sure the symmetry is there (at least 
not in all the code paths), and the logic to prevent reflective field 
update is borderline unspecifiable (*) and, even w/o considering that, 
inconsistent with what the implementation does, so it should be fixed 
one way or another.

Maurizio

(*) 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?

>
> 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.)