----- Original Message ----- > From: "Jochen Theodorou" <blackd...@gmx.org> > To: "dev" <dev@groovy.apache.org> > Sent: Sunday, January 28, 2024 1:19:24 PM > Subject: Re: [EXT] Re: ClassFile API
> On 27.01.24 18:58, Remi Forax wrote: > [...] >> 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. > Hello, before i answer to your questions, my remark about sealed types is that the API of the classfile library is based on sealed types and pattern matching. A sealed type is not extensible meaning that if you target a specific version of the classfile API, you have to manage the fact that a new subtype of a hierarchy can appear in the next version. > What would happen if we did read a sealed class, without knowing about > sealed classes? Your comment sounds like this then cannot be read, since > the specific type is required, one which we do not know, because we do > not know sealed classes. > > ... that does indeed limit the usability a lot. > > But it is still more than today. We normally do not need to read code > blocks. So as long as the bytecode change is limited to that or if the > class simply got compiled with the newest JDK it would still work. If you do not read the attribute corresponding to a sealed type, Groovy will not reject a user defined class, defined as a subtype of a selaed type that is not in the set of the permitted subtypes so the VM will reject the code at runtime with a weird error message. > > >> 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. > > With target a new LTS you mean use the new bytecode features of that? > Because just for the heck of it I do not need to update the bytecode > version I produce. yes, users may want to use new features (by example records) that are gated by a specific version of the classfile. > > For now I think the benefits from using the class file API are too low. > >>> 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. > > How does Java do that? Here is the current VM spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20240116/specs/value-objects-jvms.html Here is the current JEP https://openjdk.java.net/jeps/401 If a class V is declared as a value class, and a class A uses the class V, the class A should contain a new attribute Preload that lists "V" as a class to preload. Preloading the class allows the VM to see that a class is not a normal class but a value class (if you ask for preloading a normal class, the VM will do nothing more). When the VM knows that a class is a value class, internally the way to pass parameters is changed (the values of the fields are sent instead of a pointer) and on stack/in registers the values of the field are used instead of a pointer. So at runtime, it's like if they were no boxing. This is true for user defined value class but also some classes of the JDK like Integer, Boolean, etc or Optional that are retrofitted to be value class. > > bye Jochen regards, Rémi