What java is getting in the future is immutable data values where the reference is the value.
When you have something like
class Foo {
int a;
int b;
}
var c = new Foo();
When values land, the representation of `c` can instead be (the JVM gets to decide, it could keep the old definition for various performance reasons) something like [type, a, b]. Or in C++ terms the memory layout can be analogous to the following:
struct Foo { int a, int b };
struct Foo c;
c.a = 1;
c.b = 2;https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Even records are not value-based types, but rather are classes limited to value-like semantics - e.g. they can't extend types, are expected to have immutable behavior by default where modification creates a new record instance, and the like.
The JVM theoretically can perform escape analysis to see that a record behaves a certain way and can be stack allocated, or embedded within the storage of an aggregating object rather than having a separate heap allocation.
A C# struct gets boxed to adapt it to certain things like an Object state parameter on a call. The JVM theoretically would just notice this possibility and decide to make the record heap-allocated from the start.
I say theoretically because I have not tracked if this feature is implemented yet, or what the limitations are if it has been.
Valhala is supposed to bring language level support, the biggest issue is how to introduce value types, without breaking the ABI from everything that is in Maven Central kind of.
Similar to the whole async/await engineering effort in .NET Framework, on how to introduce it, without adding new MSIL bytecodes, or requiring new CLR capabilities.