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.
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.
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.
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?
bye Jochen
