----- Mail original ----- > De: "Alex Buckley" <alex.buck...@oracle.com> > À: "amber-spec-experts" <amber-spec-experts@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, 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. 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
