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

[Alex Buckley]

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.

Alex