----- Original Message ----- > From: "Jochen Theodorou" <blackd...@gmx.org> > To: "dev" <dev@groovy.apache.org> > Sent: Saturday, January 27, 2024 12:35:40 PM > Subject: Re: [EXT] Re: ClassFile API
> 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. The classfile API uses sealed types, once those will be updated either the groovy compiler will need to be updated or a default of a switch will be called. See how the overview of the API uses "default" everywhere. https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html I do not see how it changes anything for Groovy. If there is a new version of the classfile format, and you need to read it, then you have to modify your code each time there is a new version. For example, if a future version of Java uses a new modifier, a new bytecode instruction, a new constant pool constant or a new attribute (Valhalla add several of those), the java compiler will be modified to read and write those new modifier/instructions/constants/attributes, Groovy will have to do the same, independently of using ASM or not. The ClassFile API will not help you, because the semantics of the version classfile is different from the previous version so the code of Groovy has to be upgraded. The ClassFile API is great if your library/application only generate bytecodes (this is mostly what the JDK does BTW) because in that case, you do not have to update to each new classfile versions, only update when you want to target a new LTS. > > 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. It's not only new bytecode, by example with the value type of Valhalla, you need to generate the attribute Preload to inform the VM that the class of a value type has to be loaded before the value types appears in signature of methods and fields. If you fail to do that, it will work, value classes are backward compatible with identity (classical) classes but you will not get any optimization so any benchmarks of Groovy vs Java will be unfair. > > bye Jochen Rémi
