Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?by HexDecOctBin
- 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.by DarkNova6
- Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability
- Is there a theoretical reason why they can’t?
As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.
- 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.by cogman10
- 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.
by nogridbag - 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.
by swaranga - I 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.
by DarkNova6 - 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.
by cogman10 - 2934 commits OMG... huge work.by germandiago
- 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.by jurgenburgen
- It's a project years in the making.by estebank
- Yes, massive respect for that type of perseverance on long term, important changes.
- 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...
by andrybak - 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?
- > 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.
by ivanjermakov - 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.
by weinzierl - Wait, what? Virgil targeting the JVM does rely on that to represent vacuous arrays like `Array<void>`. That's annoying.by titzer
- 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.by ivolimmen
- 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.by josefx
- 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.by agilob
- 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.
by sheept - 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??by LoganDark
- The withdrawn of that proposal made me so sad. It would be amazing for JS as language, specially with certain use cases.
- JavaScript still doesn't have proper integers.by grishka
- > 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...
by ErenayDev - > 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.
by nalekberov - 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.by hawk_
- I personally would never compare the two. Someone said: java to JavaScript is like car to carpet. And I completely agree with that.by ivolimmen
- 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 pointby swiftcoder