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 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 ). -Chris.