> Generic types such as List<T> and Comparable<T> can be instantiated with value classes as the type arguments.
> JEP 218, Generics over Primitive Types (with revisions), will allow generic classes and methods to specialize field, array, and local variable layouts when parameterized by value class types.
Ok now this is cool! JVM needs more ways to use compile time known value sizes for better memory allocation and optimizations.
I used to love Java mostly for its batteries-included well designed standard library. Despite the verbosity of the language itself. But over time the language has really evolved a lot and gotten a lot more pleasing to the eye (in my opinion).
At some point I thought there was no way back compared to C#.
But nowadays I see the language improved a lot, avoided async/await and added virtual threads, added records, now Valhalla, decent lambdas and tons of quality of life improvements.
In the meantime C# became a monster of 2000 ways to declare properties init get, set, backed, not backed, stackalloc, structs, etc.
And I know it is done for performance: but Java is still you have a value type or a reference type. That simple. And now, on top of it Valhalla.
I think Java stayed overall more stable and simple.
C# is still pretty good, but it is just more complicated.
What I love the most is the sheer amount of thought and philosophy put into Valhalla. It transcends the binary understanding of object vs value and actually defines 4 distinct buckets:
1: Classical Object
2: Object without identity
3: Atomic Value
4: Classical Value (Tearable)
Each bucket has clearly defined performance characteristics and semantic constraints. So depending on the nature of your data, you can always get some benefit from values even if you couldn't go all the way. This is a work of art.
this comment reads like a parent who can’t help but love their child unconditionally and uncritically.
That’s a lot of complexity a lot of other languages don’t even need. It’s great Java designers have managed to shoe horn something in, but it’s all because of misdesigns 30ish years ago mispredicting of computer architecture.
While I agree with the comment being overly-praise-y, this is complexity that any multithreaded language with mutability and reasonable sanity/safety desires (but without intrusive compile-time rules a la Rust) has; others just might pretend some of the options don't exist / aren't desirable. (..and value objects, as landed in the PR, doesn't yet have tearable objects)
the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere?
and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all
I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.
IMHO, the main reason why Spring is huge is because it has grown organically to encompass many of the business cases/issues that one may encounter in both depth and breadth. So the http framework supports almost everything you may ever need and there is integration with every database, middleware, infra like kubernetes. (One can debate about the quality of all the lesser used modules but the main modules are pretty okay.)
On the other hand I have used Quarkus which was great until it wasn’t because a certain http feature wasn’t supported or we needed integration with an unsupported database. In enterprise that is enough reason to just choose for the batteries included option and lift along on improvements of the main framework.
i am building my own framework on top of it[1].
the biggest thing for me was it was rewritten on virtual threads from grounds up. no vertx. no netty, lesser indirections.
Most languages simply don't have all the frameworks that were created specifically for use in an enterprise context. There's cobol and there's maybe C#, Java and then a long tail of everything else.
A lot of the Java stuff actually came out of the Smalltalk community. IBM used to employ a lot of these people and they brought their enterprise stuff with them when things like Enterprise Java Beans became a thing. And because IBM was there, you got everybody else showing up as well. That's why Oracle bought Sun as well to get access to that juicy market.
IBM could have picked any language. But Java was kind of there and new at the time and it kind of did the job. So that's what they jumped on. MS stole a bit of the thunder with dot Net a few years later which is why C# is also very common in that space. But besides that there isn't a whole lot that has similarly wide adoption. Client side is a whole different story of course.
And the reason stuff gets complicated is that there is a lot of design by committee going on in this world by parties that are mutually adversarial and have big budgets.
So, this particular feature comes out of at least 15 (I think) years or so being debated in that sort of committee. It kind of predates the whole inception creation of things like Kotlin. I was at a 15 year birthday party for that at the Jetbrains office in Berlin a few weeks ago. Debates about value classes in the Java community probably go back to last century.
Today it is a great language with a runtime that is unequaled. For heavy duty business backend server load, it is the standard choice, and rightfully so.
Do I love Spring? No. Do I prefer Typescript for my little side projects? Yes.
I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as much as possible.
Rhis is the correct way to do it in enterprise environments.
C++ gets a lotof rage for doing the same thing.
The last thing you want in an enterprise environment is that your working code breaks and you have to commit more time to things that were working before.
What I do like about java is that when breaking changes must happen (and they do occasionally), they are almost always small and the java authors signpost it WELL in advance of making the break.
For example, this is technically legal in Java and will probably work today. Both foo and bar will synchronize on the same referenced object due to the integer cache.
This is something that will break when value types land for real.
I think that, with all things on the table, backwards compatibility, a spec and, where things are broken things are signaled should be the standard for enterprise grade non-toy apps.
Of course, breaking something should be kept to the minimum.
That is why I keep using C++ and, if I have to do backend in the future for webs, I will probably choose Java over C#: stable, multi-vendor, will work in 10 years, stable.
Agreed. I'm just happy that Java is willing to make a break when necessary. They do an excellent job of avoiding it at all costs but they won't nuke a very needed feature (like value types) if they can't deliver it without making some small breaks.
You can be pretty sure that a jar compiled for Java 1.0 will work on a Java 25 VM, and that's pretty great.
None of that prevents Java from blowing up their language with complex features. They are somehow able to sit back and work on proposals for years and end up with what makes sense for the language.
Java is to JavaScript what a Car is to Carpet. Very different beasts, though a lot of V8 work was inspired by Hotspot that's just because of common VM patterns not the syntax of the languages.
I've been annoyed too by the lack of Temporal support in Safari. It's supposedly behind a --useTemporal flag, but I've never been able to get flags to work even when launching the binary directly, and I can't find anything in developer options or feature flags settings either so like. Does it even exist at all??
I keep forgetting the reasoning for this part of the design - why is the value semantics baked in the declaration site and not at the use site?
Why does the class author have to declare it as a value type? I know this has been rehashed before many times by Brian but I keep forgetting the reasoning.
Call site is tricky because you need safety guarantees about the underlying data for it to be a value type. For example, it needs to be immutable.
If you were to call a function with a site declared value type, the function you call would have to have syntax as well to indicate "this is a value type I'm receiving and not a regular type" so that it doesn't do an illegal operation with the value type.
Java has a mechanism for Integer and Long objects caching using something that already looks like value object, cached objects can be compared using ==. hashCode of Integer already returns int, the boxed int value. Not much of value is lost.
That is a nice piece piece of knowledge! We have an Integer cache in our product, and the only reason that it hangs around is that it caches 0..1024 instead of -127..128. By setting this value, we could simplify our code, ever so slightly.
Any project depending on Integer identity had years of warning that this change would come. Also given implicit primitive conversions and object pooling Integer isn't exaclty a prime candidate for object identity to begin with.
As far as I understood this (plus future work) will make value classes work more like structs meaning it will save memory and align memory better for things like gRPC, etc.
That's great, even though specialized generics are still missing. I think these improvements will be especially beneficial for Scala, because it is such a powerful language, but abstracting on the JVM comes at a heavy price.
You can recover the history using their tooling build on top of their bugtracker and GitHub. Specifically they capture the discussions and all small changes over time in their skara tools and are prepared to leave GitHub if needed. They had multi de adres experience and had multiple prior code repos. Still do if i understand as the Oracle team has the sun and bea code repositories pre openjdk preserved.
Seems like a horrible way to work. Why could this not have landed as a large amount of smaller PRs in a more incremental fashion, maybe Java users could have gotten some value out of it earlier.
Out of all factors this certainly isn't it. If anything, more projects could learn from the way Valhalla was handled.
It started out as a highly invasive, highly disruptive and highly experimental branch that eventually turned into a beautiful specification that put semantics and performance payoff first and syntax seconds.
Unless CPU instructions become widespread that allow to process 128 bits in one step, then yes. Java will have the same limitations as any other language. Other languages simply don't make this explicit.
IIUC value objects can have any size, it's just that 'reference flattening' requires the object to fit into a machine word. But this is only due to how Java represents object references and its atomicity guarantees.
Naturally, a language that properly supports value semantics does not have any of these limitations.
Java has the mantra of "Integrity by default" which means you can tear into non-integral value type with a flag.
This is the strength of Valhalla. Instead of a binary object/value choice you have different levels of semantic guarantees that will give you better performance characteristics, depending on what your type will be able to give up.
You can have tearability for a complex/quaternion number without problem. But if you have something such as a Range-type class, that gets more problematic because cross-field constraints can be violated.
I don’t understand this comment - the .NET CLR supports arbitrarily large value types. Are you referring to something like “atomic flattening of those types” instead? Because the CLR doesn’t guarantee that, and therefore supports flattening.
Basically JEP401 guarantees that just adding "value" to the class won't change behaviour, which also means that you are not allowed to see object tearing, which requires atomic operations on the field.
Relaxing that would break safe publication rules, at least for Java.
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform.
This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.
> For the primitive types longer than 32 bits (long and double), it is not guaranteed that reads and writes from different threads (without suitable coordination) are atomic with respect to each other. The result is that, if accessed under data race, a long or double field or array component can be seen to “tear”, where a read might see the low 32 bits of one write, and the high 32 bits of another. (Declaring the containing field volatile is sufficient to restore atomicity, as is properly coordinating with locks or other concurrency control.)
Not for atomic writes, which is the important bit here. When dealing with concurrency the choice to make us will you allow tears when writing i.e. thread A writes aa and thread B writes bb. Will you allow the option of seeing ab or ba or only aa/bb. This is the thing that costs performance. Plus do you allow null which makes it harder too.
That being said, x86_64 has supported 128-bit atomic writes via cmpxchg16b for over a decade. Modern 64-bit ARM has several ways to do them as well.
Probably still not widespread enough for OpenJDK to unconditionally assume it's supported, but I think we're getting there. (Is there "caniuse" for CPU features?)
It's about the semantic guarantees because you don't want to introduce a parallel programming bug just because you added a field to a type. Tearability is opt in and if you are serious about performance you will make the correct choice.
> Generic types such as List<T> and Comparable<T> can be instantiated with value classes as the type arguments.
> JEP 218, Generics over Primitive Types (with revisions), will allow generic classes and methods to specialize field, array, and local variable layouts when parameterized by value class types.
Ok now this is cool! JVM needs more ways to use compile time known value sizes for better memory allocation and optimizations.
I feel lonely in that: I mostly love Java as a language.
The lack of value types is the biggest impediment to certain types of performance. I am really looking forward to this evolution of the language.
I used to love Java mostly for its batteries-included well designed standard library. Despite the verbosity of the language itself. But over time the language has really evolved a lot and gotten a lot more pleasing to the eye (in my opinion).
At some point I thought there was no way back compared to C#.
But nowadays I see the language improved a lot, avoided async/await and added virtual threads, added records, now Valhalla, decent lambdas and tons of quality of life improvements.
In the meantime C# became a monster of 2000 ways to declare properties init get, set, backed, not backed, stackalloc, structs, etc.
And I know it is done for performance: but Java is still you have a value type or a reference type. That simple. And now, on top of it Valhalla.
I think Java stayed overall more stable and simple.
C# is still pretty good, but it is just more complicated.
What I love the most is the sheer amount of thought and philosophy put into Valhalla. It transcends the binary understanding of object vs value and actually defines 4 distinct buckets:
1: Classical Object
2: Object without identity
3: Atomic Value
4: Classical Value (Tearable)
Each bucket has clearly defined performance characteristics and semantic constraints. So depending on the nature of your data, you can always get some benefit from values even if you couldn't go all the way. This is a work of art.
this comment reads like a parent who can’t help but love their child unconditionally and uncritically.
That’s a lot of complexity a lot of other languages don’t even need. It’s great Java designers have managed to shoe horn something in, but it’s all because of misdesigns 30ish years ago mispredicting of computer architecture.
While I agree with the comment being overly-praise-y, this is complexity that any multithreaded language with mutability and reasonable sanity/safety desires (but without intrusive compile-time rules a la Rust) has; others just might pretend some of the options don't exist / aren't desirable. (..and value objects, as landed in the PR, doesn't yet have tearable objects)
java the language is amazing
the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere?
and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all
none of these are language problems
I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.
IMHO, the main reason why Spring is huge is because it has grown organically to encompass many of the business cases/issues that one may encounter in both depth and breadth. So the http framework supports almost everything you may ever need and there is integration with every database, middleware, infra like kubernetes. (One can debate about the quality of all the lesser used modules but the main modules are pretty okay.)
On the other hand I have used Quarkus which was great until it wasn’t because a certain http feature wasn’t supported or we needed integration with an unsupported database. In enterprise that is enough reason to just choose for the batteries included option and lift along on improvements of the main framework.
+1 for Helidon (https://helidon.io/) - such a great framework, especially the SE variant. Powerful, modern, fast, modularised, and easy to understand.
I'm back on Spring for work reasons but use it for all my side-projects.
i am building my own framework on top of it[1]. the biggest thing for me was it was rewritten on virtual threads from grounds up. no vertx. no netty, lesser indirections.
1. https://github.com/sku0x20/stopgap
I was not aware of Helidon. Looks nice at first sight!
Most languages simply don't have all the frameworks that were created specifically for use in an enterprise context. There's cobol and there's maybe C#, Java and then a long tail of everything else.
A lot of the Java stuff actually came out of the Smalltalk community. IBM used to employ a lot of these people and they brought their enterprise stuff with them when things like Enterprise Java Beans became a thing. And because IBM was there, you got everybody else showing up as well. That's why Oracle bought Sun as well to get access to that juicy market.
IBM could have picked any language. But Java was kind of there and new at the time and it kind of did the job. So that's what they jumped on. MS stole a bit of the thunder with dot Net a few years later which is why C# is also very common in that space. But besides that there isn't a whole lot that has similarly wide adoption. Client side is a whole different story of course.
And the reason stuff gets complicated is that there is a lot of design by committee going on in this world by parties that are mutually adversarial and have big budgets.
So, this particular feature comes out of at least 15 (I think) years or so being debated in that sort of committee. It kind of predates the whole inception creation of things like Kotlin. I was at a 15 year birthday party for that at the Jetbrains office in Berlin a few weeks ago. Debates about value classes in the Java community probably go back to last century.
> Most languages simply don't have all the frameworks that were created specifically for use in an enterprise context
And yet a lot of enterprises have done without in other languages.
Show me where IStatusChangeEntityCreationManagerFactory is in the language. Or the standard libraries. Or anything like it
https://docs.spring.io/spring-framework/docs/current/javadoc...
Today it is a great language with a runtime that is unequaled. For heavy duty business backend server load, it is the standard choice, and rightfully so.
Do I love Spring? No. Do I prefer Typescript for my little side projects? Yes.
Fortunately, there are plenty of mature alternatives to Spring these days.
Agreed but apparently BigCorp hasn’t gotten the news yet.
I think it is important to understand what this does and does not cover. This is “only the first part of Valhalla”. See e.g. a good summary at https://www.jvm-weekly.com/p/project-valhalla-explained-how-...
I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as much as possible.
Rhis is the correct way to do it in enterprise environments.
C++ gets a lotof rage for doing the same thing.
The last thing you want in an enterprise environment is that your working code breaks and you have to commit more time to things that were working before.
What I do like about java is that when breaking changes must happen (and they do occasionally), they are almost always small and the java authors signpost it WELL in advance of making the break.
For example, this is technically legal in Java and will probably work today. Both foo and bar will synchronize on the same referenced object due to the integer cache.
This is something that will break when value types land for real.
Yes. Having a strong spec helps also in general.
I think that, with all things on the table, backwards compatibility, a spec and, where things are broken things are signaled should be the standard for enterprise grade non-toy apps.
Of course, breaking something should be kept to the minimum.
That is why I keep using C++ and, if I have to do backend in the future for webs, I will probably choose Java over C#: stable, multi-vendor, will work in 10 years, stable.
Agreed. I'm just happy that Java is willing to make a break when necessary. They do an excellent job of avoiding it at all costs but they won't nuke a very needed feature (like value types) if they can't deliver it without making some small breaks.
You can be pretty sure that a jar compiled for Java 1.0 will work on a Java 25 VM, and that's pretty great.
Whatever Java is doing seems a few orders of magnitude smoother and saner than C++ (and I like C++).
It depends on how you look at it.
C++ is very different since it is native.
Java is a VM.
This affects lots of decisions in weird ways.
But in essence both commit to backwards stability at the end.
C++ goes for performance, JVM for a more full-featured bytecode vm, etc. but still.
None of that prevents Java from blowing up their language with complex features. They are somehow able to sit back and work on proposals for years and end up with what makes sense for the language.
It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of JavaScript:
- Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari.
- Java has switch expressions, while JavaScript, despite its Scheme influence, does not.
- And now Java is getting value objects, while JavaScript's equivalent tuples & records proposal has been withdrawn.[0]
JavaScript was not developed as a fork of Java, but much of its basic syntax still resembles Java, so I think it's fair to compare them.
[0]: https://github.com/tc39/proposal-record-tuple
I personally would never compare the two. Someone said: java to JavaScript is like car to carpet. And I completely agree with that.
Reminds me of one of C++'s talks from Andrei Alexandrescu:
"std::allocator is to allocation what std::vector is to vexation".
There was another transparency inside:
"std::allocator is to allocation what alligator is to allegation".
> Someone said: java to JavaScript is like car to carpet.
You mean the sibling who commented five minutes before you?
The saying has been in use since at least 2018, so I think "someone" is accurate.
https://www.keycdn.com/support/difference-between-java-and-j...
as ham is to hamster
Java is to JavaScript what a Car is to Carpet. Very different beasts, though a lot of V8 work was inspired by Hotspot that's just because of common VM patterns not the syntax of the languages.
> Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari.
i think Temporal API added in latest preview version of safari.
https://webkit.org/blog/18182/release-notes-for-safari-techn...
The withdrawn of that proposal made me so sad. It would be amazing for JS as language, specially with certain use cases.
JavaScript still doesn't have proper integers.
> JavaScript was not developed as a fork of Java, but much of its basic syntax still resembles Java, so I think it's fair to compare them.
It's absolutely irrelevant to compare these two languages. Calling the former "Javascript" was just a marketing trick.
The original version was Scheme, but they made it look like Java for marketing, too.
I've been annoyed too by the lack of Temporal support in Safari. It's supposedly behind a --useTemporal flag, but I've never been able to get flags to work even when launching the binary directly, and I can't find anything in developer options or feature flags settings either so like. Does it even exist at all??
It is enabled by default in STP, so presumably it will launch alongside the 27 releases.
Note Temporal was in the Ecmascript 2026 release back in March.
I keep forgetting the reasoning for this part of the design - why is the value semantics baked in the declaration site and not at the use site?
Why does the class author have to declare it as a value type? I know this has been rehashed before many times by Brian but I keep forgetting the reasoning.
Call site is tricky because you need safety guarantees about the underlying data for it to be a value type. For example, it needs to be immutable.
If you were to call a function with a site declared value type, the function you call would have to have syntax as well to indicate "this is a value type I'm receiving and not a regular type" so that it doesn't do an illegal operation with the value type.
It's really nice to see movement here finally. Lack of value types has been one of the biggest performance pitfalls in Java for decades at this point
If I understand this correctly then Integer becomes a value class and every instance of it loses its object identity.
I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.
Java has a mechanism for Integer and Long objects caching using something that already looks like value object, cached objects can be compared using ==. hashCode of Integer already returns int, the boxed int value. Not much of value is lost.
Of particular note, all 1-byte Integers are interned, there is a pool of small Integers from -127 <-> 127 which are reused whenever possible.
I learned this the hard way, when a C++ JNI extension I was working on accidentally overwrote the pooled value for zero, and all hell broke loose...
> Integers from -127 <-> 127
The cache can be extended on startup with env var `java.lang.Integer.IntegerCache.high `
https://github.com/openjdk/jdk/blob/cc278dbb8a1ca0754d584270...
That is a nice piece piece of knowledge! We have an Integer cache in our product, and the only reason that it hangs around is that it caches 0..1024 instead of -127..128. By setting this value, we could simplify our code, ever so slightly.
Yeah - it's a bit non-intuitive you can change the value of a number.
https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...
In Python 2 you could literally do
and of course in JavaScriptAny project depending on Integer identity had years of warning that this change would come. Also given implicit primitive conversions and object pooling Integer isn't exaclty a prime candidate for object identity to begin with.
As far as I understood this (plus future work) will make value classes work more like structs meaning it will save memory and align memory better for things like gRPC, etc.
Wait, what? Virgil targeting the JVM does rely on that to represent vacuous arrays like `Array<void>`. That's annoying.
That's great, even though specialized generics are still missing. I think these improvements will be especially beneficial for Scala, because it is such a powerful language, but abstracting on the JVM comes at a heavy price.
Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability
Is there a theoretical reason why they can’t?
As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.
From what I gathered the core problem is flattenability. It is backed by a dynamic array and you would need real templating to remove the indirection.
They are researching to have immutable arrays. Also multifields (stack allocated arrays as fields in value classes). So, there is a possibility.
No theoretical reason; It's backward compatibility/internal technicalities, as they mention in the JEP.
2934 commits OMG... huge work.
There is just a high level of a professionalism around the whole project. Who is sponsoring all of this? Do they all work for Oracle?
The way pull requests and commits work in the OpenJDK repository -- a bot squashes each pull request into one commit: https://github.com/openjdk/jdk/pull/31120#issuecomment-51378...
The final singular commit is cc278db (8389219: Implement JEP 401: Value Objects (Preview), 2026-07-31) https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
Is there a writeup on why they choose to destroy the history?
You can recover the history using their tooling build on top of their bugtracker and GitHub. Specifically they capture the discussions and all small changes over time in their skara tools and are prepared to leave GitHub if needed. They had multi de adres experience and had multiple prior code repos. Still do if i understand as the Oracle team has the sun and bea code repositories pre openjdk preserved.
Yes, massive respect for that type of perseverance on long term, important changes.
My favorite feature from Java is the same as my favorite feature from C++: pick something 10 years later or more, and it works nearly flawlessly.
Also, now on the Java side: I think they made a great job avoiding async/await and using virtual threads. Amazing results.
I also like all the work done around structured concurrency.
It's a project years in the making.
Seems like a horrible way to work. Why could this not have landed as a large amount of smaller PRs in a more incremental fashion, maybe Java users could have gotten some value out of it earlier.
Out of all factors this certainly isn't it. If anything, more projects could learn from the way Valhalla was handled.
It started out as a highly invasive, highly disruptive and highly experimental branch that eventually turned into a beautiful specification that put semantics and performance payoff first and syntax seconds.
This is incremental. This change is the smallest possible one that could work. There are more coming in later.
What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?
Unless CPU instructions become widespread that allow to process 128 bits in one step, then yes. Java will have the same limitations as any other language. Other languages simply don't make this explicit.
IIUC value objects can have any size, it's just that 'reference flattening' requires the object to fit into a machine word. But this is only due to how Java represents object references and its atomicity guarantees.
Naturally, a language that properly supports value semantics does not have any of these limitations.
Java has the mantra of "Integrity by default" which means you can tear into non-integral value type with a flag.
This is the strength of Valhalla. Instead of a binary object/value choice you have different levels of semantic guarantees that will give you better performance characteristics, depending on what your type will be able to give up.
You can have tearability for a complex/quaternion number without problem. But if you have something such as a Range-type class, that gets more problematic because cross-field constraints can be violated.
I don’t understand this comment - the .NET CLR supports arbitrarily large value types. Are you referring to something like “atomic flattening of those types” instead? Because the CLR doesn’t guarantee that, and therefore supports flattening.
That is exact problem.
Basically JEP401 guarantees that just adding "value" to the class won't change behaviour, which also means that you are not allowed to see object tearing, which requires atomic operations on the field.
Relaxing that would break safe publication rules, at least for Java.
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform.
This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.
What is terability in this context? Not a Java expert but 20 years coding and did not hear of this.
From Valhalla's design notes[0]:
> For the primitive types longer than 32 bits (long and double), it is not guaranteed that reads and writes from different threads (without suitable coordination) are atomic with respect to each other. The result is that, if accessed under data race, a long or double field or array component can be seen to “tear”, where a read might see the low 32 bits of one write, and the high 32 bits of another. (Declaring the containing field volatile is sufficient to restore atomicity, as is properly coordinating with locks or other concurrency control.)
... ...
[0] - https://openjdk.org/projects/valhalla/design-notes/state-of-...
We've had MMX for a while now, I don't think we need to wait much longer.
I don't really see why you would need specific hardware to express a type in a programming language, though.
Not for atomic writes, which is the important bit here. When dealing with concurrency the choice to make us will you allow tears when writing i.e. thread A writes aa and thread B writes bb. Will you allow the option of seeing ab or ba or only aa/bb. This is the thing that costs performance. Plus do you allow null which makes it harder too.
That being said, x86_64 has supported 128-bit atomic writes via cmpxchg16b for over a decade. Modern 64-bit ARM has several ways to do them as well.
Probably still not widespread enough for OpenJDK to unconditionally assume it's supported, but I think we're getting there. (Is there "caniuse" for CPU features?)
It's about the semantic guarantees because you don't want to introduce a parallel programming bug just because you added a field to a type. Tearability is opt in and if you are serious about performance you will make the correct choice.
It's mostly a performance question in order to adhere to Java's memory model.
You can deliberately opt out of it though and for such a mainstream language such as Java, this just might be the sane choice.
But if I don't care for object atomicity, can I get struct-like behaviour in Java for arbitrary large types?
The MR is closed
This is it https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
https://github.com/openjdk/jdk/pull/31120#issuecomment-51378...
How much of Valhalla is this? 50% of it? 90% of it?
50% maybe.
There are other projects that depend having it in place, SIMD (vectors), reiffed generics, non nullable types.