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

[forax at univ-mlv.fr]

> 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, [ mailto:forax at univ-mlv.fr | 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. 

> -Chris.

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201110/65e52b2d/attachment.htm>