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.
