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

Chris Hegarty chris.hegarty at oracle.com
Thu Dec 10 14:35:20 UTC 2020


> On 10 Dec 2020, at 14:11, 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.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201210/a3ff0bcc/attachment-0001.htm>


More information about the amber-spec-experts mailing list