An API like this works fine for straightline code. But if you need to add
instructions conditionally, repeat blocks for additional instances, or other
complex scenarios; builders can quickly break down. I would wait to see how
the class file api shakes out before turning over nearly all of classgen. As
long as ASM keeps upping its version handling we don't need something else.
Is there a strong case that can be made for using this new api? Otherwise, I'd
like to avoid "shiny object" syndrome and focus on fixing more bugs.
-----Original Message-----
From: Jochen Theodorou <blackd...@gmx.org>
Sent: Tuesday, January 23, 2024 11:28 AM
To: dev@groovy.apache.org
Subject: [EXT] Re: ClassFile API
External Email: Use caution with links and attachments.
On 22.01.24 01:23, Daniel Sun wrote:
> Hi Jochen,
>
> Groovy relies on ASM lib directly, so it would save lots of work if we
> could have an abstract layer whose API aligns with ASM lib, just change ASM
> package name(org.objectweb.asm) with Groovy package name, e.g.
> org.apache.groovy.classfile.
yes, but how do you
´´´
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_();
});
´´´
with an ASM style of API? The lambdas make a mapping not nice
bye Jochen
