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 <fo...@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
