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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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
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'm back on Spring for work reasons but use it for all my side-projects.
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.
Do I love Spring? No. Do I prefer Typescript for my little side projects? Yes.
- 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
"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".
You mean the sibling who commented five minutes before you?
https://www.keycdn.com/support/difference-between-java-and-j...
i think Temporal API added in latest preview version of safari.
https://webkit.org/blog/18182/release-notes-for-safari-techn...
It's absolutely irrelevant to compare these two languages. Calling the former "Javascript" was just a marketing trick.
Note Temporal was in the Ecmascript 2026 release back in March.
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.
I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.
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...
https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...
The cache can be extended on startup with env var `java.lang.Integer.IntegerCache.high `
https://github.com/openjdk/jdk/blob/cc278dbb8a1ca0754d584270...
As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.
The final singular commit is cc278db (8389219: Implement JEP 401: Value Objects (Preview), 2026-07-31) https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
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 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.
Naturally, a language that properly supports value semantics does not have any of these limitations.
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.
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.
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.
I don't really see why you would need specific hardware to express a type in a programming language, though.
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?)
This is it https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
There are other projects that depend having it in place, SIMD (vectors), reiffed generics, non nullable types.