Should final fields in records be trusted or not trusted in 16?

[forax at univ-mlv.fr]

> De: "Chris Hegarty" <chris.hegarty at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>, "mandy chung" <mandy.chung at 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:forax at univ-mlv.fr | forax at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201210/0aabadc8/attachment.htm>