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 changed, the
application layer of the system need not any changes, just implement the API to
support the target database.
Class-File API supports writing bytecode, e.g.
´´´
ClassBuilder classBuilder = ...;
classBuilder.withMethod("fooBar", MethodTypeDesc.of(CD_void, CD_boolean,
CD_int), flags,
methodBuilder -> methodBuilder.withCode(codeBuilder -> {
Label label1 = codeBuilder.newLabel();
Label label2 = codeBuilder.newLabel();
codeBuilder.iload(1)
.ifeq(label1)
.aload(0)
.iload(2)
.invokevirtual(ClassDesc.of("Foo"), "foo", MethodTypeDesc.of(CD_void,
CD_int))
.goto_(label2)
.labelBinding(label1)
.aload(0)
.iload(2)
.invokevirtual(ClassDesc.of("Foo"), "bar", MethodTypeDesc.of(CD_void,
CD_int))
.labelBinding(label2);
.return_();
});
´´´
On 2024/01/22 19:15:58 "Milles, Eric (TR Technology) via dev" wrote:
> 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 switchable like the others should not be too
> problematic. Did we want to make such a thing pluggable so user could
> introduce their own class lookup option?
>
