On 11/10/2020 1:09 PM, fo...@univ-mlv.fr wrote:
*De: *"Chris Hegarty" <chris.hega...@oracle.com>
*À: *"Remi Forax" <fo...@univ-mlv.fr>
*Cc: *"amber-spec-experts" <amber-spec-experts@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, fo...@univ-mlv.fr
<mailto:fo...@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
