final fields in record

Brian Goetz brian.goetz at
Wed Nov 13 16:50:20 UTC 2019

As much as I detest that there are various ways to write final fields, I do not think that trying to key off of records to prevent this has the right return-on-complexity.  (Perhaps different story for values). 

Sent from my MacBook Wheel

> On Nov 13, 2019, at 3:52 PM, Remi Forax <forax at> wrote:
> It occurs to me that given that record is a new construct, we can fix an error from the past [1], final field not really be final.
> Obviouly, it means that refactoring a class to a record or vice-versa will not be 100% compatible, but given that we have already introduced Class.isRecord(), it's not 100% compatible anyway. Compared to [1], which aim to solve the problem by adding more metadata, disabling mutation of the record synthetic fields once for all has the advantages that it requires less memory (and less possible deopt).
> Given that records are immutable and that there is a special mechanism to deserialize them,
> it think we should disallow records synthetic fields to be changed at runtime using reflection, JNI, Unsafe etc.
> I believe the JLS has to be updated a bit to explicitly says that you can not change the synthetic fields of a record even by reflection during deserialization,
> the reflection Field.set() has to be amended, etc.
> And in the VM, the function `trust_final_non_static_fields` should add a case to trust record fields.
> regards,
> Rémi
> [1]

More information about the amber-spec-experts mailing list