On 22.01.24 20:15, Milles, Eric (TR Technology) via dev wrote:
The new Class File API is for reading not writing, correct?
I had a different impression. Sure, reading is a big use case for normal
Javausers, but they are currently moving their bytecode generation as
well. For example for proxies
There are many bytecode lib in the Java world, an abstract layer for handling
bytecode can prevent Groovy from the change of implementation. It is similar to
system with data persistence layer which provides unified API to access
databases, e.g. MySQL, PostgreSQL, Oracle, etc. If database change
The new Class File API is for reading not writing, correct? With that in mind,
I think only the ASM decompile package (org.codehaus.groovy.ast.decompiled) is
under consideration. There are already 2 paths taken by ClassNodeResolver
tryAsLoaderClassOrScript. Adding a third option there that is
