Fwd: Bytecode transforming record class to be mutable
Brian Goetz
brian.goetz at oracle.com
Wed Aug 17 15:14:37 UTC 2022
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>
More information about the amber-dev
mailing list