final fields in record

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 13 Novembre 2019 17:50:20
> Objet: Re: final fields in record

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

the idea was more to single out the plain old class,
by an accident of the history, enum fields can be non final but hidden class (and its non public counterpart VM anonymous class) and inline class already have their final fields as really final.

Rémi

> 
> Sent from my MacBook Wheel
> 
>> On Nov 13, 2019, at 3:52 PM, Remi Forax <forax at univ-mlv.fr> 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] https://bugs.openjdk.java.net/browse/JDK-8233873