Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?

[Olexandr Rotan]

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.

Annotations such as @Async and @Transactional 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.

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.

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.

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.

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.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240917/c7b3c3eb/attachment.htm>