For me, you are focusing on the wrong side of the time line,
trusted final fields should be the new normal and plain old classes are the
ones that are weird because they have a *weak* final fields semantics.
So instead of saying that records, hidden classes, anonymous classes (and soon
primitive object classes) are special, the VM should say that plain old classes
are the outlier.
In an ideal world, yes, although I don't think wishing that does
anything for our current issue(s) with records.
Btw, for the records, the work described here:
https://bugs.openjdk.java.net/browse/JDK-8233873
iis what's required to enable final field optimization _safely_ (stress
this word many times, please) for _all_ classes. But that's besides the
point.
The point in my email is that just attaching an attribute (the record
attribute) to a class doesn't magically remove the safety concerns
associated with trusting final fields (some of which are captured in the
above RFE). With the current mechanism for trusted final fields we still
have to double check that trusted finals cannot be updated. So there has
to be a symmetry between the logic granting the trusts and the logic
which keeps the platform on a safe ground by rejecting final fields updates.
In the current situation, I'm not sure the symmetry is there (at least
not in all the code paths), and the logic to prevent reflective field
update is borderline unspecifiable (*) and, even w/o considering that,
inconsistent with what the implementation does, so it should be fixed
one way or another.
Maurizio
(*) Field::set doesn't fail when Class::isRecord returns true (which is
what we currently specify) but when the class the field belongs to has
the Record attribute. Should we add that to the javadoc?
With that, the JLS definition of a record doesn't need to leak into the JVMS.
Maurizio
Rémi
On 11/11/2020 02:39, Dan Smith wrote:
On Nov 10, 2020, at 1:51 PM, Chris Hegarty <chris.hega...@oracle.com> wrote:
My issue is with how the VM determines whether a field is trusted or not. The VM
trusts fields in (among other types) “record” classes. So what is a record
class to the VM? (that is the question that I am trying to resolve) - the
answer is not in the JVMS ( which is fine ).
Suggestion: the VM shouldn't bother to provide any definition for "record
class". That's up to Java language compilers and reflection (which should be in
agreement).
Instead, can't we say the VM trusts fields in classes that have a Record
attribute? Who cares whether those classes are "real" records or not? (I may be
missing something because I don't fully understand the concept of "trusted
final field", but it seems to me like HotSpot has a lot of freedom to decide to
trust or not trust whatever fields it wants.)
