<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"amber-dev" <amber-dev@openjdk.java.net><br><b>Sent: </b>Wednesday, August 17, 2022 5:14:37 PM<br><b>Subject: </b>Fwd: Bytecode transforming record class to be mutable<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4"><font face="monospace">This was received on the
-comments list.<br><br>
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.) <br><br>
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.) <br><br>
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. </font></font></blockquote><div><br></div><div>Yes, the chapter 4.7 of the VM spec says that the record attribute is "not critical to correct interpretation of the <code class="literal">class</code> file by the Java Virtual Machine, but are either critical to correct interpretation of the <code class="literal">class</code> file by the class libraries of the Java SE Platform, or are useful for tools".<br data-mce-bogus="1"></div><div><a href="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</a><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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).</div><div><br data-mce-bogus="1"></div><div>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.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
</th>
<td>Bytecode transforming record class to be mutable</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
<td>Wed, 17 Aug 2022 16:50:09 +0200</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
<td>Christian Beikov <a class="moz-txt-link-rfc2396E" href="mailto:christian.beikov@gmail.com" target="_blank"><christian.beikov@gmail.com></a><br data-mce-bogus="1"></td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:amber-spec-comments@openjdk.org" target="_blank">amber-spec-comments@openjdk.org</a><br data-mce-bogus="1"></td>
</tr>
</tbody>
</table>
<br>
<br>
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.<br>
<br>
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:<br>
<br>
* Make fields for record components non-final<br>
* Add additional fields that are not set through the canonical
constructor, nor exposed through record component attributes<br>
<br>
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...<br>
<br>
Cross posting from StackOverflow:
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/73377190/bytecode-transforming-record-class-to-be-mutable" target="_blank">https://stackoverflow.com/questions/73377190/bytecode-transforming-record-class-to-be-mutable</a><br>
<br>
Regards,<br>
<br>
Christian<br>
<br>
</div><br></blockquote></div></div></body></html>