Bytecode transforming record class to be mutable

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "amber-dev" <amber-dev at openjdk.java.net>
> Sent: Wednesday, August 17, 2022 5:14:37 PM
> Subject: Fwd: Bytecode transforming record class to be mutable

> 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.
Yes, the chapter 4.7 of the VM spec says that the record attribute is "not critical to correct interpretation of the class file by the Java Virtual Machine, but are either critical to correct interpretation of the class file by the class libraries of the Java SE Platform, or are useful for tools". 
[ https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html#jvms-4.7 | https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html#jvms-4.7 ] 

The VM should not reject such classfile but libraries consumming such classfile (including the reflection) may not work properly (this also disable the constantification of record fields by the JITs). 

I understand the appeal of creating chimera like this, it's quite fun to learn how of things work but providing a librarie for others to create such beasts is quite sad. 

Rémi 

> -------- Forwarded Message --------
> Subject: 	Bytecode transforming record class to be mutable
> Date: 	Wed, 17 Aug 2022 16:50:09 +0200
> From: 	Christian Beikov [ mailto:christian.beikov at gmail.com |
> <christian.beikov at gmail.com> ]

> To: 	[ mailto:amber-spec-comments at openjdk.org | 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
> |
> 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/c9e874dd/attachment.htm>