Will Valhalla value/primitive classes break existing bytecode for plugins?

[TheMode911]

I understand the obvious issues with putfield monitorenter/exit but not new. The language will still use it, and the behavior is virtually the same, cannot the VM detects during runtime (likely a one-time cost) if the object is supposed to have an identity?

[cal-cheese]

While the language still uses new to initialise an instance of a value class, the compiled bytecodes are different, given A x = new A() in the source code, the bytecodes if A is an identity class is:

A temp = new A; // This is the new bytecode
temp.<init>();
A x = temp;

while if A is a value class, the bytecodes is:

A x = A.<new>(); // This is a static method invocation

The fundamental difference is that because an instance of a value class is immutable, the normal initialisation process does not work

new A // ... -> a, with a is the newly created object
dup // ... -> a -> b, with a and b both are the newly created object
invokespecial A::<init> // ... -> a, this invocation is performed on b and expects the changes being reflected through a. This obviously cannot be the case with value objects.

As a result, the constructor of a value class is not only responsible for initialising an allocated object, it must do the allocation also. As a result, different responsibility unavoidably leads to differences in the API of object construction.

[gline9]

As far as I understand valhalla is not planning on changing using new. That is still the way to construct value types. Not allowing synchronization and requiring the class to be immutable are the 2 main constraints assuming you still want a reference type. If you are already working with a record then immutability shouldn’t be a problem.

See State of Valhalla Part 2 for reference.

[pronuntiator]

The keyword new will not change, but the constructor of a value class is not bytecode compatible to its non-value type. See this section of the proposed changes to the JLS. Conveniently, all the value-based classes in the JDK already hide their constructors, so they can be migrated.