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

[Remi Forax]

----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 10 Novembre 2020 22:37:04
> Objet: Re: The Record Attribute - What does it mean to be a record at runtime?

> On 11/10/2020 1:09 PM, forax at univ-mlv.fr wrote:
>>     *De: *"Chris Hegarty" <chris.hegarty at oracle.com>
>>     *À: *"Remi Forax" <forax at univ-mlv.fr>
>>     *Cc: *"amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>>     *Envoyé: *Mardi 10 Novembre 2020 21:51:38
>>     *Objet: *Re: The Record Attribute - What does it mean to be a record
>>     at runtime?
>> 
>>     Remi,
>> 
>>     A point of clarification ( which I realise may have been ambiguous
>>     in my last email ).
>> 
>>         On 10 Nov 2020, at 19:36, forax at univ-mlv.fr
>>         <mailto:forax at univ-mlv.fr> wrote:
>> 
>>             ...
>> 
>>             A better option would be to update the VM implementation to
>>             only assert
>>             that the fields of a record-like class are trusted if that class
>>             contains 1) a structurally sound Record attribute, 2) is a
>>             direct
>>             subclass of j.l.Record, 3) is final, and 4) is non-abstract.
>>             This would
>>             align Core Reflection and the VM in this respect, while the
>>             JVMS would
>>             remain unchanged - it's an implementation detail.
>> 
>> 
>>         No, it's pushing the JLS semantics into the JVM.
>> 
>>         What you want to know is if a field is trusted final or not, to
>>         disallow the creation of VarHandle, the use Unsafe, etc.
>>         So the JDK API should ask the VM if a field is trusted final or
>>         not instead of asking if the class is a record.
>> 
>> 
>>     Agreed. The VM exposes a (private) interface to the core JDK
>>     libraries to tell whether a field is trusted or not. No issue.  ( I
>>     did not mean to say otherwise )
>> 
>>     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 ).
>> 
>> 
>> For me having a Record attribute is enough, i.e. the current definition
>> of what a record is for the VM is enough.
>> 
>> The problem is that if a class has to be a subclass of java.lang.Record,
>> it means that any languages that want to use the attribute Record has to
>> agree to the contract of j.l.Record,
>> by example, j.l.Record has a precise definition of how to compare
>> floating point numbers or the fact that there is an order in between the
>> record components.
>> Those kind of constraints are fine for Java the language but it's not
>> something that the VM should enforce for any other languages.
> 
> The JLS, and therefore the Java SE Platform that incorporates the JLS,
> defines what a record class is. A record class is a class that extends
> j.l.Record, has no non-static fields, has no native methods, etc. The
> Record attribute indicates that a class file wishes to be treated as a
> record class, so a compiler and the reflection libraries must hold a
> class file with a Record attribute to the standard expected of a record
> class (extends j.l.Record, etc). In principle, a JVM implementation
> could also have this responsibility, but in practice, no-one wants to do
> these exhaustive checks at class load time. So, a non-Java compiler can
> happily spin a class file with a Record attribute and no j.l.Record
> superclass, but it doesn't represent a record class and the reflection
> libraries should not say it does, hence no "trusted" final fields.

I don't disagree if the notion of trusted fields is created in the reflection API,
because currently, it's just a VM thing, not a reflection thing.

> 
> Alex

Rémi