<div dir="ltr">When I said that bytecode modification is unsafe, I was mainly regarding type safety. Compiler does a load of work to not let through invalid code, and processors that modify ast still have to pass symbol resolution checks, type checks and many other ones, while bytecode modification basically has no safety mechanisms other then runtime failure (and it's good if it fails, there may be just silent errors). In this sense, I would regard AST modification as much more preferable option if there was a public API for it</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2024 at 10:41 PM Bernd <<a href="mailto:ecki@zusammenkunft.net">ecki@zusammenkunft.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div>
</div><div><div dir="ltr">Hello,</div><div dir="ltr"><br></div><div dir="ltr">To me bytecode is a standardized interface and creating or modifying bytecode is legal and not inherently unsafe.</div><div dir="ltr"><br></div><div dir="ltr">If annotation processor authors want to use bytecode modifications they now get an additional tool for that but it doesn’t change the general usage.</div><div dir="ltr"><br></div><div dir="ltr">In the end users have to know if they want to use intransparent magic like Lombok or Pointcuts or even worse runtime agents. And this affects selecting platforms who need it or not. (And don’t forget the ecosystem is much bigger than Java language alone)</div><div dir="ltr"><br></div><div dir="ltr">Gruß</div><div dir="ltr">Bernd</div><div id="m_914770779123916159ms-outlook-mobile-signature"><div style="direction:ltr">-- </div><div style="direction:ltr" dir="auto"><a href="https://bernd.eckenfels.net" target="_blank">https://bernd.eckenfels.net</a></div></div>
<div> </div><hr style="display:inline-block;width:98%"><div id="m_914770779123916159divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>From:</b> core-libs-dev <<a href="mailto:core-libs-dev-retn@openjdk.org" target="_blank">core-libs-dev-retn@openjdk.org</a>> on behalf of Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com" target="_blank">rotanolexandr842@gmail.com</a>><br><b>Sent:</b> Tuesday, September 17, 2024 9:16 PM<br><b>To:</b> <a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a> <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>><br><b>Subject:</b> Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?<div> </div></font></div><div dir="ltr">Hello there. I am writing to address the overlap between class file transformation using the ClassFile API and the work done by code-generating annotation processors, and whether they ultimately solve the same problem.<p>Annotations such as <code>@Async</code> and <code>@Transactional</code> in popular frameworks are good examples of code semantics being modified or extended at runtime, primarily through proxying mechanisms. In these cases, bytecode transformation is employed under the hood, as the annotations imply asynchronous execution or transactional boundaries. <br><br>The general implication that I am aware of about annotations is that they can change code semantics. While I am not a fan of this, I can understand people that once set this rule. And so Class-File API exposing transformation API for class-files seems like legalizing the bypass of this rule. I, personally, am a fan of steps in this direction, since I like to write code generators that generate code for existing classes for fun from time to time, but that doesnt change my assumption that Class-File API somehow contradicts general rules applied to annotations by JDK, and it always seems kind of odd to me when some of API authors speaks so calmly about on-flight transformations of bytecode while even AST transformations in compile time aren't supported by JDK.</p><p>Moreover, Class-File API seems like more than just an alternative to generating processors, but rather a weapon of mass destruction compared to later. Changes to bytecode are always unsafe, and their versatility makes them much more invasive.<br><br>To me, personally, after this API is introduced, addressing long standing questions of libraries like lombok and more exotic ones like manifold seems to be an organic step. In my opinion, if even bytecode transformations are now legal, then much more safe AST transformations (which are safer because the compiler wont let through invalid AST, while bytecode transformations could cause silent errors) should also be addressed. SInce JDK historically mostly focused on code readability, many libraries picked up responsibility of easing writability, and "legalizing" them, in my opinion, would be a giant step in the right direction.<br><br>So what am I missing here? Or is it really as it seems, that now that bytecode transformations are in public APIs, making invasive changes in compiled code is basically legalized? Would really appreciate it if someone could spare some time to make things clear for me.<br><br>Best regards</p></div>
</div><div id="m_914770779123916159ms-outlook-mobile-signature"><div><br></div><div style="direction:ltr">-- </div><div style="direction:ltr" dir="auto"><a href="https://bernd.eckenfels.net" target="_blank">https://bernd.eckenfels.net</a></div></div></div></div>
</blockquote></div>