On 28.01.24 15:05, Remi Forax wrote:
[...]
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.
yeah, sorry for confusing you and the limited creativity. I did
understand that.. Maybe I should have taken something else as example
that changes the class level, or members. records would have given a
better example
[..]
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
oh wow... the decision with the class file version 67.65535 is a bit
strong... is it then 68.65535 in Java24? If they wanted to introduce
class file variants they could have made that differently - or not?
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.
I assume this means no change for using invokedynamic. The
implementation would have to change of course... well at least if that
is to be used there as well.
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.
So if I have a method that takes a Number as parameter there will be no
value type handling?
bye Jochen
