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

[Brian Goetz]

> Which leaves us two options:
>
> * revert the changes which allowed the VM to trust record fields
> * keep trusting record fields, but on a more solid definition of what 
> a record is (which is in line with what the JLS, and the reflection 
> API say)
>
> Any other solution IMHO seems more like an hack to me.

Agreed.   Either is fine here.

There's an aspect here (again) of falling for the siren song of a "point 
hack" for an emotionally-laden general problem.  We all hate that final 
fields are not really final, and there's a risk of being blinded by that 
hatred.  (This siren sings to us about nullity and mutability too, 
whenever there's new language surface.)

Remi a dit:

> If the definition is a class that contains a record attribute which is the current definition for the VM, then i don't see a problem if Scala Tuples or an immutable Kotlin data types are using the record Attribute.

That line of thinking is where tomorrow's problems come from!  No thanks!

> Forcing the semantics of Java into the VM is always a bad idea.

I think describing this particular thing as "forcing language semantics 
into the VM" is a bit of an exaggeration, but I certainly have no 
problem with the conclusion: revert the optimization and invest the 
dividend in making it more general.