8 ms·
JEP 401: Value Objects (Preview) merged to OpenJDK master
- germandiago 3mo ago2934 commits OMG... huge work.
- estebank 3mo agoIt's a project years in the making.
- thibaut_barrere 3mo agoYes, massive respect for that type of perseverance on long term, important changes.
- germandiago 3mo agoMy 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.
- jurgenburgen 3mo agoSeems 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.
- DarkNova6 3mo agoOut 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.
- krzyk 3mo agoThis is incremental. This change is the smallest possible one that could work. There are more coming in later.
- andrybak 3mo agoThe 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-5137845497 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/cc278dbb8a1ca0754d5842708b9029441055d361 https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
- fulafel 3mo agoIs there a writeup on why they choose to destroy the history?
- jerven 3mo agoYou 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.
- J-Kuhn 3mo agoBefore 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.
- fulafel 3mo agoHmm. 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.
- groundzeros2015 3mo agoThere is just a high level of a professionalism around the whole project. Who is sponsoring all of this? Do they all work for Oracle?
- brunoborges 3mo agoValhalla is 99% done by Oracle, yes.
- groundzeros2015 3mo agoI’m impressed by their uncharacteristic discipline and long term vision. In the big tech I know this would get pushed early.
- brunoborges 2mo agoI'd say it is very characteristic of the Java team at Oracle to be committed to discipline and long term vision. I strongly suggest watching some of their talks from JVMLS (JVM Language Summit), especially the ones from Brian Goetz and Mark Reinhold. https://www.youtube.com/playlist?list=PLX8CzqL3ArzUOgZpIX6GsoRhPbnij-sco https://www.youtube.com/playlist?list=PLX8CzqL3ArzUOgZpIX6Gs...
- whytevuhuni 3mo agoHow much of Valhalla is this? 50% of it? 90% of it?
- ligarota 3mo agoThe MR is closed This is it https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842708b9029441055d361 https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
- moritzwarhier 3mo agohttps://github.com/openjdk/jdk/pull/31120#issuecomment-5137847090 https://github.com/openjdk/jdk/pull/31120#issuecomment-51378...
- weinzierl 3mo agoIf 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.
- agilob 3mo agoJava 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.
- swiftcoder 3mo agoOf 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...
- agilob 3mo ago> 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/cc278dbb8a1ca0754d5842708b9029441055d361/src/java.base/share/classes/java/lang/Integer.java#L927 https://github.com/openjdk/jdk/blob/cc278dbb8a1ca0754d584270...
- pwagland 3mo agoThat 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.
- tpm 3mo agoYeah - it's a bit non-intuitive you can change the value of a number. https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Edition https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...
- HexDecOctBin 3mo agoWhat's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?
- DarkNova6 3mo agoUnless 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.
- Smaug123 3mo agoI 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.
- pwagland 3mo agoThat 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.
- DarkNova6 3mo agoYou 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.
- germandiago 3mo agoWhat is terability in this context? Not a Java expert but 20 years coding and did not hear of this.
- deleted 3mo ago[deleted]
- timmg 3mo agoI 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.
- MrBuddyCasino 3mo agoToday 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.
- DarkNova6 3mo agoFortunately, there are plenty of mature alternatives to Spring these days.
- MrBuddyCasino 3mo agoAgreed but apparently BigCorp hasn’t gotten the news yet.
- ksec 2mo agoWhat are those alternatives? I haven't touched Java for web development for a very very long time.
- vips7L 2mo agoQuarkus, Micronaut, Helidon are all the big players. Quarkus has the most market share and is quite enjoyable to work with.
- merlindru 3mo agojava 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
- sheept 3mo agoIt'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 https://github.com/tc39/proposal-record-tuple
- LoganDark 3mo agoI'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??
- dwaite 3mo agoIt 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.
- hawk_ 3mo agoJava 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.
- ivolimmen 3mo agoI personally would never compare the two. Someone said: java to JavaScript is like car to carpet. And I completely agree with that.
- kleiba2 3mo ago
- swiftcoder 3mo agoIt'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
- parallax_error 3mo agoReally cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability
- fallingbananna 3mo agoIs 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.
- theanonymousone 3mo agoNo theoretical reason; It's backward compatibility/internal technicalities, as they mention in the JEP.
- DarkNova6 3mo agoFrom 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.
- joe_mwangi 3mo agoThey are researching to have immutable arrays. Also multifields (stack allocated arrays as fields in value classes). So, there is a possibility.
- J-Kuhn 3mo agoThe 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)
- 3mo ago
- ludovicianul 3mo agoI'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.
- germandiago 3mo agoRhis 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.
- cogman10 3mo agoWhat 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. void foo() { Integer i = 1; synchronized(i) { doEvil(); } } void bar() { Integer i = 1; synchronized(i) { doEvil(); } }
- germandiago 3mo agoYes. 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.
- cogman10 3mo agoAgreed. 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.
- mormegil 3mo agoI 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-a https://www.jvm-weekly.com/p/project-valhalla-explained-how-...
- cogman10 3mo agoI 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.
- pregnenolone 3mo agoThat'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.
- deleted 3mo ago[deleted]
- swaranga 3mo agoI 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.
- cogman10 3mo agoCall 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.
- DarkNova6 2mo agoI think it keeps going back to "preserving type invariants". Turning an object into a value can have surprising constraints on the integrity of the type. These include: forced empty constructor (for bulk initialiation in arrays), violation of cross-field invariance (think of a Range-type where "end" value is suddenly smaller than the "start" due to a data race), etc. Java always had a focus on enabling library authors over empowering call-site users. And I think approach has proven its dividend.
- ivanjermakov 3mo ago> 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.
- z0ltan 3mo ago[dead]
- kuhsaft 3mo agoPrevious HN discussion on project Valhalla: https://news.ycombinator.com/item?id=48595511 https://news.ycombinator.com/item?id=48595511
- exabrial 3mo agoModern Java friggen rocks. I honestly cannot understand why you would use anything but the OG these days!
- dionian 3mo agoscala 3 exists
- vips7L 3mo agoIf you want to punish yourself.
- spopejoy 2mo agoAt 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.
- hn4yci687u 3mo ago[dead]
- nirvdrum 3mo agoIf 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.