The Record Attribute - What does it mean to be a record at runtime?
Alex Buckley
alex.buckley at oracle.com
Tue Nov 10 21:37:04 UTC 2020
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
More information about the amber-spec-experts
mailing list