The Record Attribute - What does it mean to be a record at runtime?
Remi Forax
forax at univ-mlv.fr
Tue Nov 10 21:46:19 UTC 2020
----- 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
More information about the amber-spec-experts
mailing list