On 23.01.24 19:33, Milles, Eric (TR Technology) via dev wrote:
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.
the only reason I see is one of the reasons Class File exists and that
is to be able to read/write class files of the newest Java version. Yes,
sure if Groovy X.32.50 supports Java 32 and then Java 33 is released we
can, after some months, update the asm lib and release Groovy X.33.0.
But this also means (a) we are required to release and (b) Groovy
X.32.50 will never support ordinary classes compiled to Java 33.
It is also a question of when we can have work started on implementing
any new bytecode based features of the new Java variant. the point might
be for mood since we rarely have the manpower to do something like this.
bye Jochen
