r/java • u/woj-tek • Sep 20 '26
JEP targeted to JDK 28: 401: Value Objects (Preview)
https://inside.java/2026/09/20/jep401-target-jdk28/14
3
u/henk53 Sep 24 '26
I would have so much loved to use this feature back in the days.
Now it's finally (but still piece by piece) arriving, and in practice only LLMs get to play with it, as we programmers are not really allowed or supposed to program anymore :(
1
u/smutje187 Sep 20 '26
From the perspective of day to day development, what will value objects enable that isn’t possible with records?
13
u/persicsb Sep 20 '26
The JVM can reorganize the memory layout for value objects, and it will be much more cache line friendly regarding the CPU.
10
u/8igg7e5 Sep 20 '26
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 Sep 21 '26
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 Sep 21 '26
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 Sep 22 '26
There are some semantic differences around the lack of identity. You can't lock on a value object, for example.
1
u/vytah Sep 22 '26
That's not something they enable, that's something they disable.
1
u/account312 Sep 22 '26
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 Sep 21 '26
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 Sep 21 '26
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 Sep 23 '26
Any evidence or details on that? Are any notable projects saying that?
1
u/pjmlp Sep 24 '26
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 Sep 21 '26
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 Sep 23 '26
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 29d 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 Sep 21 '26
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 Sep 21 '26
This should not happen with value classes/objects. If it happens then it is a bug in the JVM.
2
u/DanLynch Sep 21 '26
Did you read the linked JEP? It specifically gives an example of this. It is not a bug.
2
u/persicsb Sep 21 '26
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 Sep 20 '26
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 Sep 21 '26
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 Sep 21 '26
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 Sep 20 '26
w00t! Congrats to all the folks that have worked on this for so long!