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.
It's work of art and a work of science, I'd say. Programming language dev needs both, and I think Java has learned how to do both, at least compared to its messy early years.
On the note of science, I'll credit Java's maintainers for treating their language as a technology and not merely as a product. Many languages respect the real-world physics of computers to stay relevant. Few respect the "metaphysics" until weird bugs keep emerging in the compiler and ecosystem. Bugs that can't be solved with more building, engineering, or even design. Because those bugs are not defects; they come from the concepts & axioms of the language itself, not its implementation.
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.
I think you've misunderstood, because not only would this have been the right design if it had been in Java since day one as it's in line with the philosophy of the platform, it's also simpler than in other languages.
The idea is that instead of controlling memory layout and referencing directly, you communicate your intent: do you care about this value's identity or not? Do you need atomicity or not? Do you need nullability or not? Once the intent is clear, the compiler is free to choose the most appropriate and efficient layout for the particular value at the particular use site. In other words, you say what semantics you're interested in rather than how to implement them at the lowest level.
This opens up optimisation opportunities that are lost when the programmer directly controls the representation rather than the intent. E.g. in other languages you may say whether you want to pass some value by reference or by value. Here the compiler is free to say, well, if identity and nullability are not needed here, I can either pass by value or by reference, and I'll do whichever is more efficient.
And by the way, your point about early misdesign (whether it applies here or not) also inverts the desired state. Every language makes decisions that will be suboptimal in the environment some time later, and Java certainly has its share (its mutability and nullability default; how it treats serialisation). Rust, for example, was first designed twenty years ago, and some of its fundamental decisions reflect the state of the world at that time (it went all-in on some C++ premises that seemed fine 20 years ago). But since important codebases often outlast the outdatendness of early language decisions (your OS and your browser are running some >30yo code and/or affected by >30yo design decisions), one of the things most important in a language isn't the decisions it makes early on - some will prove "wrong" while your codebase is still alive and kicking - but how well it adapts and evolves. So when you pick a language for an important project today, the language's current state will end up mattering less than how the language evolves in the future. The question asked isn't "will I like this decision today?" but "will I regret this decision ten years from now?" Java is one of the languages with the lowest "regret factor", possibly lowest of them all.
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)
I think it really highlights how important it was to have atomicity and integrity by default because even here people will handwave away any such concerns as if they don’t exist.
Your comment makes no sense to me, but I must grant that there is a lot of bad reporting about Valhalla and I’ve been following the mailing lists for well over 7 years now.
Nothing, absolutely nothing about the design is a compromise that would detract from the project if it was for any other language.
You could judge them for bringing “complexity to an easy topic” but it really is far from that and the idea of a value type being a distinct dichotomy from an object is just a convenient tradition.
The push for immutability and value-ness has been going on for a long time and the motivation of the project was to bring performance benefits that align with semantic statements about the underlying data type. Which is of course a more nuanced take than “go value, go faster”.
Classical object, object without identity, atomic value, and classical value are not simplifications that you’d want in other languages. Rust, Haskell, Python - none of them need or would benefit from any of this.
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.
They added so much new syntax to C# to the point it really is starting to feel like C++++ whereas Java has modernized itself without massively expanding its syntax and modifiers.
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.
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.
Just adding the bare bones integration wasn’t that hard. The trick comes from ensuring all the observability is wired correctly, that it fits in the framework usage, works good with graalvm, and other “non-functionals”.
At this point the work is typically more than you want a single team to maintain. Unfortunately, in many large enterprises it is just easier and more efficient to grab a bigger framework than trying to organise sharing the custom integration in the organisation.
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.
This is specifically Spring culture, not Java culture in general. I don't tend to see this outside of Spring. Maybe back in the J2EE days, but that community seems to be more or less dead.
Java is a big tent. Yeah there are some parts that deserve this kind of mockery.
The Rails equivalent is over-metaprogramming. "I solved it with method_missing." I've worked on code like this in real life. TBH I'd rather have the inane verbose class names.
I-prefixing interfaces is a practice from Microsoft's COM, and to this day still isn't part of Java culture, despite the efforts of subversive dotnet renegades.
I have an opinion on why. If you were in that world 25+ years ago, you'll be familiar with the landscape. There were a dozen popular application servers, each with 15 versions in the wild, all running on premises, and you had to ship software to customers who had wildly different operations. It helped. It's verbose. As you said, this mostly attributable to JEE and projects that traded build time complexity and home-grown code for abstraction complexity.
I had to support systems from IBM, BEA, Apache, Red Hat, SAP, and some I'm certainly forgotten. Then there were the piecemeal systems. OSGi made an appearance. Then you have databases from Oracle, Microsoft, and IBM. Identity and auth was the wild west, with countless SSO vendors, wacky LDAP implementations, wackier SAML implementations, Kerberos, Ping... Despite that, it was pretty feasible to build and ship the same artifacts and configure things at the site.
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.
There's always this comment on every Java post. I expect the average HN member to be someone on the team who is either leading their projects or plays a significant role in driving the design of the software. You set the culture for your own projects. I've lead the development of some massive Java apps and all have had simple and clean architecture. I've never seen IStatusChangeEntityCreationManagerFactory or anything like it even once in any of my projects, but perhaps that's because the last time I used Spring was ~17 years ago. Most of my recent projects are using Quarkus, which is still a relatively large framework. But our codebase is designed in such a way that we're not tightly coupled to Quarkus.
I have seen a surge of overly complicated PRs now that we're in the AI era, but it's our job to be the gatekeeper and push back on this crud from entering the codebase. And that's likely true of any language.
You’re not alone! I love Java too. It is excellent.
I don’t reach for it much anyone since I prefer TypeScript’s type system and the ability to use the same language for both client/server, but I’m never upset to write some Java :)
You shouldn't be. I do like Java a lot, and recent changes (and speed of those) just makes it more and more better.
And I appreciate and I'm under huge awe to the amount of though put into the evolution -- instead of just cramming every new shiny thing they ponder it a lot to arrive at the most sensible option while trying their best to maintain backward compatibility -- kudos!
I agree fully. It may not be perfect but it works really well, has a huge community, and I like the language.
I mostly ignore online discussions about Java. So much of it just feels like memes. Complaining about things that haven’t been valid in a very long time. Sometimes almost 2 decades.
It feels a bit like people bashing Nickelback. It was the “cool” thing to do. Maybe they’ve never used Java. Or only for one college course.
People can dislike Java. I’m sure some do. It’s fine. But it seems like the anti opinion is really over represented/amplified.
I don’t do programming for a living (i manage infrastructure) but i have a very fond memory of java from the earliest days of my career.
I really really think that java is weighted down by all the ceremonial enterprise stuff that has accumulated over the years.
Lightweight frameworks are somewhat recent, otherwise you really couldn’t print a text/plain http response without bringing up a whole application server and a whole ecosystem of libraries (j2ee)
That will not happen for backward compatibility reasons but a new build tool with a modern CLI would be nice. One that's declarative like Maven (without the XML) and doesn't require an upgrade for every new JDK version like Gradle (screw Gradle).
I've said this before but I'll say it again: The worst part of Java is Java programmers.
For most of my career, I thought I hated Java, primarily because every piece of Java code I had ever worked with was overly verbose across a million different files to do things that would take like ten lines of code in any other language.
Then I actually started looking at all the features for Java 8, 11, 17, and 21, and realized: NO! Java actually gives lots of really great tools and language features that allow you to write relatively pretty, terse, performant code. Record types help cut down on a lot of boilerplate stuff, the streams API allows for pretty work over lists, sealed interfaces mostly solve my itch for ADTs, virtual threads are genuinely pretty impressive bits of engineering, and for the stuff that isn't built in, Vert.x and Disruptor do a pretty good job filling in the gaps.
Once I learned all that, I was kind of mad at people still writing code like it was 1999, but also started to enjoy writing Java. It helps that by this time I was already senior and staff level, meaning I was given much more leeway in how code was written (so the poor junior engineers are stuck/blessed dealing with my code using all the shiny new features).
For companies that deployed Java this is the best part. Growth of Java from 1995-2015 and enterprise IT outsourcing was almost in lockstep. It was not for programmers with taste or interest in coding. It was J2EE 1000 page manual printed and distributed in bulk at IT vendors describing things in hugely verbose details with dummy pet-store project to use all facets of Java/J2EE that ingrained into overall Java culture.
It could be business or politeness reasons that well meaning Java language authors rarely spoke a word against this wider Java culture. So it was just assumed that overtly verbose code and organization of Java projects have official stamp to it.
Yeah, I guess I always just found it miserable to work on.
When I worked at a BigCo [1], our project was a big monorepo in Java which had 60,000 folders, and I don't remember how many files. It was decidedly no fun to work on, because everything was spread across a million files and so doing anything required sifting through dozens or even hundreds of files. I hated it.
I've worked on giant projects since then, but they've been written in more modern Java and they are less painful.
[1] It's not hard to find the specific one through my history but I politely ask you do not post it in reply to this post.
I'd say a lot of verbosity comes from generalization -- when you want the code to be reusable and moddable (pluginable). No wonder two widely moddable games (Minecraft and Kerbal Space Program) are written in Java and C# respectively, makes it very easy to create mods. Once I tried to make a Go project at least build-time moddable and found myself creating a lot of java-esque Factories and Builders.
Whether that generalization is premature -- I don't know, just my observation on why.
I've written plugin systems for stuff I've worked on, and it didn't require nearly the same level of verbosity. Granted, I usually have done this with sockets instead of directly using JVM and reflection. To each their own, but I like using sockets (usually ZeroMQ) for this stuff because then it's completely language independent.
Even if I granted that you needed to use all this factory and builder glue stuff, I don't agree with the typical Java developer's strategy of breaking things up across a million files, which Java at least greatly encourages.
> No wonder two widely moddable games (Minecraft and Kerbal Space Program) are written in Java and C# respectively, makes it very easy to create mods.
It's more that it's easy to write code that links directly into the game. Easy to do because you can decompile them and make changes easily without having source code. Sure, Minecraft was obfuscated for a long time, but people put a lot of effort into deobfuscation and obfuscation removes a lot less than native compilation.
(You also don't need an official modding API this way)
Java remains unfairly tethered to a reputation forged over 20 years ago. Human psychology reveals a reluctance to update our worldview: once a collective consensus solidifies, it becomes very difficult to dismantle. Yet, to dismiss Java today is to overlook a remarkable evolution. Modern Java is an elegant, highly capable language, resting upon the Java Virtual Machine, which is a remarkable piece of technology.
I agree, but this really is one of the most important and useful parts to land. Next is the null constraints. Generics will be useful, but not needed to get a large portion of the performance benefits.
With this finally integrated, we are also likely to start seeing pretty regular performance bumps for all things value related.
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.
The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues that large C++ programs tend to suffer from (I originally made the switch to Java because it was getting hard to keep the large C++ applications we were working on fast enough; Java does some optimisations that are hard for a C++ compiler).
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.
One thing the Java architects have said is they let most of the complex feature development happen outside of Java, which is pretty nice.
They let the likes of Kotlin, C#, C++, Scala, Haskell, etc all explore their own little features then they figure out if it could be integrated with Java and what it'd look like.
I really like that approach because it's slow, methodical, and the features typically are very well aligned with Java. None of them feel particularly out of place.
Java's preview system also works pretty well to get these features refined over time.
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??
At this point I don't understand why to use a JVM language with anything but Java. Java is a "good enough" language now and is still the premier ecosystem driver, getting all of the big-budget upgrades and attention -- but it's still a PITA, mainly because of the terrible tooling surrounding deploying an app with the JVM. My point is, the JVM is both the best and the worst thing about Java, so if you're clojure (cough common lisps) or scala (cough OCAML/Haskell) it seems like you're making life hard for no reason -- there are at least equivalent if not better alternatives that can actually compile to a deployable binary.
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.
> 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.
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.
Hmm. Is this about Github or Git? Dependency on Github seems tangential to treating Git as a first class record of history.
edit: rereading, I guess the implication is that there's tooling built on top of Github outside of Git, so Git history is indeed not meant to be contain some things.
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.
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.
One misconception I had was that with value objects we could simply use `==` for comparison. But it looks like there's lots of gotchas with this especially if the value class has String fields for one or more fields. For example, comparing two ZonedDateTime value objects may be fine with == because I believe the JDK team ensured the Strings that represent the ZoneIds are always the same reference.
We have tons of wrapper classes in our codebase which seem ideal as value objects. For example, instead of passing around "String emailAddress", we have a wrapper class EmailAddress. While we can now make our EmailAddress class a value object, we cannot do "==". Unlike ZoneId in which there's a fixed set and you can intern all ZoneIds in the string pool, email addresses are unique and trying to intern all email addresses would be a bad idea. So it seems like using .equals is here to stay even for these types of basic classes.
I don't think there's a lot of gains to be had for strings. Perhaps if you are dealing with a very large amount of small strings then it could be useful, but once you get past a few characters strings it's faster to just send around a reference anyways.
The problem is not that the array is mutable, but that the size of the array may differ for different strings. (In fact, it usually* does differ if the string length is different).
This makes it impossible to flatten - as the VM needs to know the total size when creating the memory layout for a class...
* (with a small exception: if the strings use different coders, one can be twice as long and the backing arrays would still have the same size)
Indeed. At this point you’d need to bring the size of the string into the type system (C++ Templates we meet again!) but then you look at a solution worse than the problem…
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.
From elsewhere I've seen that this is something they are thinking about offering but nothing concrete has surfaced. It would be an opt-in sort of thing where you say "I'm ok with my code breaking if I misuse this class".
It will likely require you poke in the `jdk.internal` package space.
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.
If you click the “favorite” link it’ll be saved to your list of favorites. But, it doesn’t actually have to be your favorite —- it’s just a user-defined collection of HN posts.
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.
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.
It's work of art and a work of science, I'd say. Programming language dev needs both, and I think Java has learned how to do both, at least compared to its messy early years.
On the note of science, I'll credit Java's maintainers for treating their language as a technology and not merely as a product. Many languages respect the real-world physics of computers to stay relevant. Few respect the "metaphysics" until weird bugs keep emerging in the compiler and ecosystem. Bugs that can't be solved with more building, engineering, or even design. Because those bugs are not defects; they come from the concepts & axioms of the language itself, not its implementation.
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.
I think you've misunderstood, because not only would this have been the right design if it had been in Java since day one as it's in line with the philosophy of the platform, it's also simpler than in other languages.
The idea is that instead of controlling memory layout and referencing directly, you communicate your intent: do you care about this value's identity or not? Do you need atomicity or not? Do you need nullability or not? Once the intent is clear, the compiler is free to choose the most appropriate and efficient layout for the particular value at the particular use site. In other words, you say what semantics you're interested in rather than how to implement them at the lowest level.
This opens up optimisation opportunities that are lost when the programmer directly controls the representation rather than the intent. E.g. in other languages you may say whether you want to pass some value by reference or by value. Here the compiler is free to say, well, if identity and nullability are not needed here, I can either pass by value or by reference, and I'll do whichever is more efficient.
And by the way, your point about early misdesign (whether it applies here or not) also inverts the desired state. Every language makes decisions that will be suboptimal in the environment some time later, and Java certainly has its share (its mutability and nullability default; how it treats serialisation). Rust, for example, was first designed twenty years ago, and some of its fundamental decisions reflect the state of the world at that time (it went all-in on some C++ premises that seemed fine 20 years ago). But since important codebases often outlast the outdatendness of early language decisions (your OS and your browser are running some >30yo code and/or affected by >30yo design decisions), one of the things most important in a language isn't the decisions it makes early on - some will prove "wrong" while your codebase is still alive and kicking - but how well it adapts and evolves. So when you pick a language for an important project today, the language's current state will end up mattering less than how the language evolves in the future. The question asked isn't "will I like this decision today?" but "will I regret this decision ten years from now?" Java is one of the languages with the lowest "regret factor", possibly lowest of them all.
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)
I think it really highlights how important it was to have atomicity and integrity by default because even here people will handwave away any such concerns as if they don’t exist.
Your comment makes no sense to me, but I must grant that there is a lot of bad reporting about Valhalla and I’ve been following the mailing lists for well over 7 years now.
Nothing, absolutely nothing about the design is a compromise that would detract from the project if it was for any other language.
You could judge them for bringing “complexity to an easy topic” but it really is far from that and the idea of a value type being a distinct dichotomy from an object is just a convenient tradition.
The push for immutability and value-ness has been going on for a long time and the motivation of the project was to bring performance benefits that align with semantic statements about the underlying data type. Which is of course a more nuanced take than “go value, go faster”.
Classical object, object without identity, atomic value, and classical value are not simplifications that you’d want in other languages. Rust, Haskell, Python - none of them need or would benefit from any of this.
Because?
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.
100% agree.
They added so much new syntax to C# to the point it really is starting to feel like C++++ whereas Java has modernized itself without massively expanding its syntax and modifiers.
[dead]
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.
What are those alternatives? I haven't touched Java for web development for a very very long time.
Quarkus, Micronaut, Helidon are all the big players. Quarkus has the most market share and is quite enjoyable to work with.
Agreed but apparently BigCorp hasn’t gotten the news yet.
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.
> or we needed integration with an unsupported database
How difficult is/was it to add a custom integration?
Just adding the bare bones integration wasn’t that hard. The trick comes from ensuring all the observability is wired correctly, that it fits in the framework usage, works good with graalvm, and other “non-functionals”.
At this point the work is typically more than you want a single team to maintain. Unfortunately, in many large enterprises it is just easier and more efficient to grab a bigger framework than trying to organise sharing the custom integration in the organisation.
+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!
This is specifically Spring culture, not Java culture in general. I don't tend to see this outside of Spring. Maybe back in the J2EE days, but that community seems to be more or less dead.
Java is a big tent. Yeah there are some parts that deserve this kind of mockery.
The Rails equivalent is over-metaprogramming. "I solved it with method_missing." I've worked on code like this in real life. TBH I'd rather have the inane verbose class names.
I**Factory existed long before spring came around
I-prefixing interfaces is a practice from Microsoft's COM, and to this day still isn't part of Java culture, despite the efforts of subversive dotnet renegades.
Yes, more common is
Yeah, Ruby code bases are generally harder to maintain than Java ones.
I have an opinion on why. If you were in that world 25+ years ago, you'll be familiar with the landscape. There were a dozen popular application servers, each with 15 versions in the wild, all running on premises, and you had to ship software to customers who had wildly different operations. It helped. It's verbose. As you said, this mostly attributable to JEE and projects that traded build time complexity and home-grown code for abstraction complexity.
I had to support systems from IBM, BEA, Apache, Red Hat, SAP, and some I'm certainly forgotten. Then there were the piecemeal systems. OSGi made an appearance. Then you have databases from Oracle, Microsoft, and IBM. Identity and auth was the wild west, with countless SSO vendors, wacky LDAP implementations, wackier SAML implementations, Kerberos, Ping... Despite that, it was pretty feasible to build and ship the same artifacts and configure things at the site.
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.
There's always this comment on every Java post. I expect the average HN member to be someone on the team who is either leading their projects or plays a significant role in driving the design of the software. You set the culture for your own projects. I've lead the development of some massive Java apps and all have had simple and clean architecture. I've never seen IStatusChangeEntityCreationManagerFactory or anything like it even once in any of my projects, but perhaps that's because the last time I used Spring was ~17 years ago. Most of my recent projects are using Quarkus, which is still a relatively large framework. But our codebase is designed in such a way that we're not tightly coupled to Quarkus.
I have seen a surge of overly complicated PRs now that we're in the AI era, but it's our job to be the gatekeeper and push back on this crud from entering the codebase. And that's likely true of any language.
I have never run into code like that in any of my jobs.
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...
Spring is not Java. It's also one of the most complex projects out there.
> Or anything like it
Spring isn’t the language or standard libraries.
Ok, it's possible that my bilingual ahh is misunderstanding the comment. Maybe we can try to come to an understanding?
I read that comment as "Show me where [long classnames] are in the language, standard library or <relevant ecosystem project>."
Spring is one of the biggest java libraries and quite widely used. I think it fits rather nicely, even if the example itself is fairly old.
Yeah I just think you have a fundamental misunderstanding of what the ecosystem is. Spring is used less than you think.
It's clearly still very popular.
https://survey.stackoverflow.co/2025/technology#1-web-framew...
I meant anything like "IStatusChangeEntityCreationManagerFactory"
lol it’s so long it overflows the window and breaks the css on my phone.
"the language. Or the standard libraries"
it's not, that's my point
You’re not alone! I love Java too. It is excellent.
I don’t reach for it much anyone since I prefer TypeScript’s type system and the ability to use the same language for both client/server, but I’m never upset to write some Java :)
You shouldn't be. I do like Java a lot, and recent changes (and speed of those) just makes it more and more better.
And I appreciate and I'm under huge awe to the amount of though put into the evolution -- instead of just cramming every new shiny thing they ponder it a lot to arrive at the most sensible option while trying their best to maintain backward compatibility -- kudos!
You are definitely not alone. I love Java and I will always defend it. Java's perception is tainted by baggage from decades ago.
I agree fully. It may not be perfect but it works really well, has a huge community, and I like the language.
I mostly ignore online discussions about Java. So much of it just feels like memes. Complaining about things that haven’t been valid in a very long time. Sometimes almost 2 decades.
It feels a bit like people bashing Nickelback. It was the “cool” thing to do. Maybe they’ve never used Java. Or only for one college course.
People can dislike Java. I’m sure some do. It’s fine. But it seems like the anti opinion is really over represented/amplified.
I don’t do programming for a living (i manage infrastructure) but i have a very fond memory of java from the earliest days of my career.
I really really think that java is weighted down by all the ceremonial enterprise stuff that has accumulated over the years.
Lightweight frameworks are somewhat recent, otherwise you really couldn’t print a text/plain http response without bringing up a whole application server and a whole ecosystem of libraries (j2ee)
Also… the build system situation is still shit
The tooling could be better, though.
I wish it came with more batteries included, and it renovated that old Java cli split per commands, following a bit what golang did:
- java run
- java build
- java test
- java fuzz-test
- java format
- java lock
- java lsp
- etc.
Along with a better support of posix long form flags like ‘--version’.
That will not happen for backward compatibility reasons but a new build tool with a modern CLI would be nice. One that's declarative like Maven (without the XML) and doesn't require an upgrade for every new JDK version like Gradle (screw Gradle).
Maven 4 provides alternative build file syntax with extensions: https://github.com/maveniverse/mason
Is this better than the previous polyglot extension?
I've said this before but I'll say it again: The worst part of Java is Java programmers.
For most of my career, I thought I hated Java, primarily because every piece of Java code I had ever worked with was overly verbose across a million different files to do things that would take like ten lines of code in any other language.
Then I actually started looking at all the features for Java 8, 11, 17, and 21, and realized: NO! Java actually gives lots of really great tools and language features that allow you to write relatively pretty, terse, performant code. Record types help cut down on a lot of boilerplate stuff, the streams API allows for pretty work over lists, sealed interfaces mostly solve my itch for ADTs, virtual threads are genuinely pretty impressive bits of engineering, and for the stuff that isn't built in, Vert.x and Disruptor do a pretty good job filling in the gaps.
Once I learned all that, I was kind of mad at people still writing code like it was 1999, but also started to enjoy writing Java. It helps that by this time I was already senior and staff level, meaning I was given much more leeway in how code was written (so the poor junior engineers are stuck/blessed dealing with my code using all the shiny new features).
> The worst part of Java is Java programmers.
For companies that deployed Java this is the best part. Growth of Java from 1995-2015 and enterprise IT outsourcing was almost in lockstep. It was not for programmers with taste or interest in coding. It was J2EE 1000 page manual printed and distributed in bulk at IT vendors describing things in hugely verbose details with dummy pet-store project to use all facets of Java/J2EE that ingrained into overall Java culture.
It could be business or politeness reasons that well meaning Java language authors rarely spoke a word against this wider Java culture. So it was just assumed that overtly verbose code and organization of Java projects have official stamp to it.
Yeah, I guess I always just found it miserable to work on.
When I worked at a BigCo [1], our project was a big monorepo in Java which had 60,000 folders, and I don't remember how many files. It was decidedly no fun to work on, because everything was spread across a million files and so doing anything required sifting through dozens or even hundreds of files. I hated it.
I've worked on giant projects since then, but they've been written in more modern Java and they are less painful.
[1] It's not hard to find the specific one through my history but I politely ask you do not post it in reply to this post.
I'd say a lot of verbosity comes from generalization -- when you want the code to be reusable and moddable (pluginable). No wonder two widely moddable games (Minecraft and Kerbal Space Program) are written in Java and C# respectively, makes it very easy to create mods. Once I tried to make a Go project at least build-time moddable and found myself creating a lot of java-esque Factories and Builders.
Whether that generalization is premature -- I don't know, just my observation on why.
I don't agree with that though.
I've written plugin systems for stuff I've worked on, and it didn't require nearly the same level of verbosity. Granted, I usually have done this with sockets instead of directly using JVM and reflection. To each their own, but I like using sockets (usually ZeroMQ) for this stuff because then it's completely language independent.
Even if I granted that you needed to use all this factory and builder glue stuff, I don't agree with the typical Java developer's strategy of breaking things up across a million files, which Java at least greatly encourages.
> No wonder two widely moddable games (Minecraft and Kerbal Space Program) are written in Java and C# respectively, makes it very easy to create mods.
It's more that it's easy to write code that links directly into the game. Easy to do because you can decompile them and make changes easily without having source code. Sure, Minecraft was obfuscated for a long time, but people put a lot of effort into deobfuscation and obfuscation removes a lot less than native compilation.
(You also don't need an official modding API this way)
You are not alone.
Java remains unfairly tethered to a reputation forged over 20 years ago. Human psychology reveals a reluctance to update our worldview: once a collective consensus solidifies, it becomes very difficult to dismantle. Yet, to dismiss Java today is to overlook a remarkable evolution. Modern Java is an elegant, highly capable language, resting upon the Java Virtual Machine, which is a remarkable piece of technology.
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 agree, but this really is one of the most important and useful parts to land. Next is the null constraints. Generics will be useful, but not needed to get a large portion of the performance benefits.
With this finally integrated, we are also likely to start seeing pretty regular performance bumps for all things value related.
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.
The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues that large C++ programs tend to suffer from (I originally made the switch to Java because it was getting hard to keep the large C++ applications we were working on fast enough; Java does some optimisations that are hard for a C++ compiler).
Well, yes. True that for long-running apps JVM seems to be tuned.
I meant the kind of "perf-to-the-instruction" thst native can generate vs other considerations.
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.
One thing the Java architects have said is they let most of the complex feature development happen outside of Java, which is pretty nice.
They let the likes of Kotlin, C#, C++, Scala, Haskell, etc all explore their own little features then they figure out if it could be integrated with Java and what it'd look like.
I really like that approach because it's slow, methodical, and the features typically are very well aligned with Java. None of them feel particularly out of place.
Java's preview system also works pretty well to get these features refined over time.
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
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
as ant is to antidisestablishmentarianism
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.
> 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.
> It's absolutely irrelevant to compare these two languages. Calling the former "Javascript" was just a marketing trick.
Playing devil's advocate: back when you still could use Java in the browser, you could use Javascript to script your Java applets.
The original version was Scheme, but they made it look like Java for marketing, too.
> 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...
JavaScript still doesn't have proper integers.
The withdrawn of that proposal made me so sad. It would be amazing for JS as language, specially with certain use cases.
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.
Modern Java friggen rocks. I honestly cannot understand why you would use anything but the OG these days!
scala 3 exists
At this point I don't understand why to use a JVM language with anything but Java. Java is a "good enough" language now and is still the premier ecosystem driver, getting all of the big-budget upgrades and attention -- but it's still a PITA, mainly because of the terrible tooling surrounding deploying an app with the JVM. My point is, the JVM is both the best and the worst thing about Java, so if you're clojure (cough common lisps) or scala (cough OCAML/Haskell) it seems like you're making life hard for no reason -- there are at least equivalent if not better alternatives that can actually compile to a deployable binary.
If you want to punish yourself.
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...
Such hacks will slowly stop working (without explicitly allowing it from the command line.)
In this example, it would throw an IllegalAccessException, because java.base doesn't open java.lang.
Doesn’t field.setAccessible(true) already throw on a modern version?
In Python 2 you could literally do
and of course in JavaScriptThe terrifying part of this in Java, is that it applies program-wide, including to constants set before you changed the value
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.
Wait, what? Virgil targeting the JVM does rely on that to represent vacuous arrays like `Array<void>`. That's annoying.
> 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.
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?
Valhalla is 99% done by Oracle, yes.
I’m impressed by their uncharacteristic discipline and long term vision. In the big tech I know this would get pushed early.
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.
Hmm. Is this about Github or Git? Dependency on Github seems tangential to treating Git as a first class record of history.
edit: rereading, I guess the implication is that there's tooling built on top of Github outside of Git, so Git history is indeed not meant to be contain some things.
Before openjdk did move to github, they made sure they had a solution for those problems:
* Contributors without github accounts * Moving away from github (when needed) * No vendor lock-in for github stuff.
I personally think, this is a good idea - a lot of work, but may be worth it in the long run.
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.
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.
Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability
One misconception I had was that with value objects we could simply use `==` for comparison. But it looks like there's lots of gotchas with this especially if the value class has String fields for one or more fields. For example, comparing two ZonedDateTime value objects may be fine with == because I believe the JDK team ensured the Strings that represent the ZoneIds are always the same reference.
We have tons of wrapper classes in our codebase which seem ideal as value objects. For example, instead of passing around "String emailAddress", we have a wrapper class EmailAddress. While we can now make our EmailAddress class a value object, we cannot do "==". Unlike ZoneId in which there's a fixed set and you can intern all ZoneIds in the string pool, email addresses are unique and trying to intern all email addresses would be a bad idea. So it seems like using .equals is here to stay even for these types of basic classes.
I don't think there's a lot of gains to be had for strings. Perhaps if you are dealing with a very large amount of small strings then it could be useful, but once you get past a few characters strings it's faster to just send around a reference anyways.
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.
The problem is not that the array is mutable, but that the size of the array may differ for different strings. (In fact, it usually* does differ if the string length is different).
This makes it impossible to flatten - as the VM needs to know the total size when creating the memory layout for a class...
* (with a small exception: if the strings use different coders, one can be twice as long and the backing arrays would still have the same size)
Indeed. At this point you’d need to bring the size of the string into the type system (C++ Templates we meet again!) but then you look at a solution worse than the problem…
No theoretical reason; It's backward compatibility/internal technicalities, as they mention in the JEP.
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.
The Java way was always to let library designers decide how a type is used. I personally think this is the sensible one.
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?)
cmpxchg16b can only handle 64bits data correctly because of ABA problem.
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?
From elsewhere I've seen that this is something they are thinking about offering but nothing concrete has surfaced. It would be an opt-in sort of thing where you say "I'm ok with my code breaking if I misuse this class".
It will likely require you poke in the `jdk.internal` package space.
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.
The MR is closed
This is it https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
https://github.com/openjdk/jdk/pull/31120#issuecomment-51378...
Previous HN discussion on project Valhalla: https://news.ycombinator.com/item?id=48595511
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.
IMO it's the most important 50%. If this alone is delivered I'd call Valhalla a success.
Agreed. The other are nice to have.
[dead]
Bookmarked for later
If you click the “favorite” link it’ll be saved to your list of favorites. But, it doesn’t actually have to be your favorite —- it’s just a user-defined collection of HN posts.