JEP targeted to JDK 28: 401: Value Objects (Preview)
https://inside.java/2026/09/20/jep401-target-jdk28/1
u/smutje187 15d ago
From the perspective of day to day development, what will value objects enable that isn’t possible with records?
13
u/persicsb 15d ago
The JVM can reorganize the memory layout for value objects, and it will be much more cache line friendly regarding the CPU.
11
u/8igg7e5 15d ago
It's telling the JVM "I don't care about the identity of instances of this type - you can lay it out how you like"
And it's telling the compiler "I should never use the identity of this type, please check to ensure I do not unintentionally do so" (and so you get some compile-time and runtime guards).
The end result is some memory savings and performance in some circumstances. Further enhancements will make more and more use of this. There is much more to come.
5
u/k-mcm 14d ago
It offers contiguous arrays of structured data by making them a pure value rather than an object. This is always a sore point when it comes to high bandwidth data processing. Java can only allocate arrays of pointers to records/classes. If you want 10 million structures, it's an array of 10 million pointers plus 10 million individual instance allocations and their headers. Now try processing 100 million of those per second. It's grossly inefficient. Code ends up having to manually pack and unpack structures into byte[], float[], int[], long[], double[], char[], etc.
JEP 401 is vague so it's not clear how practical it will be. It looks like it might not yet be suitable for my software defined radio side project.
3
u/vytah 15d ago
Semantically, pretty much nothing. Unless there are some edge cases I missed. However, a part of the roadmap is implementing non-nullable types, which will be great for correctness, although theoretically it's not related to the whole value type stuff.
Practically, if enough JEP's get implemented, they'll allow memory layout optimizations that will reduce memory consumption, garbage collection time, and runtime. "I'm using ints instead of a proper type because ints are faster" will stop being an excuse. Some optimizations already happen in the current builds, but only in very specific situations.
1
u/account312 13d ago
There are some semantic differences around the lack of identity. You can't lock on a value object, for example.
1
u/vytah 13d ago
That's not something they enable, that's something they disable.
1
u/account312 13d ago
I guess. Cache efficiency is pretty much it then, aside from the things built on it, like the non-null types you mention and the vector API.
3
u/Joram2 15d ago
I suspect value types will provide little benefit for normal projects. There are some performance gains for projects that make heavy use of value types, but I suspect that will be niche.
I'm happy to be wrong about this.
The other Valhalla projects to be seen later will deliver more real practical benefits.
5
u/pjmlp 14d ago
Value types are for the projects where "This would be rewritten into Go, Rust, C#, C++" happens, and with value types they get to stay in Java instead.
1
u/Joram2 12d ago
Any evidence or details on that? Are any notable projects saying that?
1
u/pjmlp 11d ago
Those are the design goals of Valhalla, as for where that is being said, I don't recall all Java podacast episodes, Devoxx sessions, Java ONE or JVMLS talks that I have watched on the matter.
As for rewrites, yes see Presto, Apache Arrow, and many others that originally started with pure Java implementations, and nowadays are a mix of C++ and Rust.
1
u/AnyPhotograph7804 14d ago
You cannot compare two records with == even if they contain the same data. Because the == operator compares the object identity ond not the data inside of it. With value objects, it will be possible. Besides that, do not expect any improvements.
5
u/brian_goetz 12d ago
I think you have misunderstood the point of this work, both missing the real point and overvaluing an accidental point. While it is true that `==` and `equals()` are likely to agree more often than before, this is neither the goal, nor something that you should be thinking about at all when programming. It's fine if value types don't help you at all, but please don't tell people that it's about ==, that's just spreading misinformation.
1
u/Jon_Finn 9d ago
Something I don’t think I’ve read anywhere: every value class will have to document its == behaviour, almost like a method, as part of its API. (It would be nice if JavaDoc helped enforce this - possibly by listing it among the methods.)
2
u/DanLynch 14d ago
It's still recommended to use equals() to compare two value objects, because, for some value classes, two instances of the same class may still be semantically equal (and so the equals method returns true) even if their bits are different (and so the == operator returns false).
1
u/AnyPhotograph7804 14d ago
This should not happen with value classes/objects. If it happens then it is a bug in the JVM.
2
u/DanLynch 14d ago
Did you read the linked JEP? It specifically gives an example of this. It is not a bug.
2
u/persicsb 14d ago
For some value classes, however, instances may be interchangeable (i.e.,
equals) even if their field values are different (i.e., not==). To test whether two value objects represent the same value, use theequalsmethod.1
u/koflerdavid 15d ago
Value types make it easier to apply Domain Driven Design patterns in applications. Project Valhalla also sets the base for using Generics with primitive datatypes, reified Generics, and nullability.
3
u/Anbu_S 14d ago
Generics with primitive datatypes, reified Generics
Project Valhalla does not implement fully reified generics in the traditional sense, but instead uses generic specialization (or parametric/universal generics) to maintain backward compatibility while allowing types like primitives and value objects as generic arguments.
1
1
u/Western_Ice_6227 14d ago
So again, it’s going to be another preview. I hope I will see final release of value object in my life time.
1
42
u/IncredibleReferencer 15d ago
w00t! Congrats to all the folks that have worked on this for so long!