> De: "Chris Hegarty" <chris.hega...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>, > "amber-spec-experts" > <amber-spec-experts@openjdk.java.net>, "mandy chung" <mandy.ch...@oracle.com> > Envoyé: Jeudi 10 Décembre 2020 15:35:20 > Objet: Re: Should final fields in records be trusted or not trusted in 16?
>> On 10 Dec 2020, at 14:11, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >> wrote: >>> ... >> There is a third choice see above. >> Forcing the semantics of Java into the VM is always a bad idea. >> We don't do that for any other constructs, lambda, enums, Java anonymous >> classes, etc. >> Worst, we already know that an inline record is not a record from the JLS >> POV. >> For Java 16, given that we are late in the process, i see no problem if the >> VM >> doesn't trust record fields as a temporary patch, if it's easier than to have >> Field.set() to ask if a class is a plain class or not. It's far better than >> having the the JLS definition of a record bolted into the VM. > In my view, this is an “everyone loses” option. > If we do not prevent Field.set() from modifying the fields of a record > class in Java 16, then it will be almost impossible to do so at some > future point. The intermediate step that we’re proposing both allows > for 1) TNSFF in record classes, and 2) an evolution path to a more > general mechanism in the future. I do not see that no.1 is covered by > option three. yeah, you maybe right because records is not a preview feature anymore, i've forgotten that important "detail". > -Chris. Rémi
