Fwd: Bytecode transforming record class to be mutable

[Brian Goetz]

This was received on the -comments list.

This is definitely an abuse, which may have been done out of ignorance 
(transform all the classes, without looking very carefully) or out of 
cleverness-toxicity (many people's judgment gets turned off when they 
think they're being clever.)  But generating "mutable records" is a 
serious party foul, and we should treat it the way normal communities 
treat party fouls -- with shame (and if that doesn't work, banishment.)

The JVM has some awareness of record-ness (e.g., the Record attribute, 
primarily used to support reflection), but like with so many features, 
the JVM can't enforce every requirement that the language enforces (and 
often shouldn't.)

Most ORMs have figured out how to work with immutable carriers. The 
EBean community should be encouraged to do the same, or to not try to 
work with records.  These attempts to "rewrite rules you don't like" may 
offer the author a brief frisson of perceived "sticking it to the man", 
but ultimately just pollute the community, to everyone's detriment.


-------- Forwarded Message --------
Subject: 	Bytecode transforming record class to be mutable
Date: 	Wed, 17 Aug 2022 16:50:09 +0200
From: 	Christian Beikov <christian.beikov at gmail.com>
To: 	amber-spec-comments at openjdk.org



I just saw that EBean does bytecode transformation of record class files 
in a way that feels odd to me and I seek an answer about whether this is 
legal from a JVM point of view.

Apparently, it is possible to have a class file, where the class extends 
`java.lang.Record` and defines record component attributes (so it's a 
"record" like javac would create it), but with the following additional 
"features" which javac would not allow:

* Make fields for record components non-final
* Add additional fields that are not set through the canonical 
constructor, nor exposed through record component attributes

To me, this seems illegal and I would have expected a JVM verification 
error. I would like to know if this is something that is "supported", 
which I can build upon, or if the lack of verification is a JVM bug. Are 
records just a Java language feature without JVM support?! I read that 
final fields of records are "truly final" and can't be changed even 
through reflection and assumed there must be special JVM support that 
makes sure records match the Java language semantics...

Cross posting from StackOverflow: 
https://stackoverflow.com/questions/73377190/bytecode-transforming-record-class-to-be-mutable

Regards,

Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220817/36ca7b39/attachment-0001.htm>