Rendered at 08:48:01 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
timmg 1 hours ago [-]
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.
MrBuddyCasino 38 minutes ago [-]
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.
ludovicianul 29 minutes ago [-]
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.
sheept 1 hours ago [-]
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.
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??
swiftcoder 1 hours ago [-]
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
parallax_error 36 minutes ago [-]
Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability
fallingbananna 26 minutes ago [-]
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.
theanonymousone 9 minutes ago [-]
No theoretical reason; It's backward compatibility/internal technicalities, as they mention in the JEP.
weinzierl 2 hours ago [-]
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.
agilob 2 hours ago [-]
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.
swiftcoder 1 hours ago [-]
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...
agilob 31 minutes ago [-]
> Integers from -127 <-> 127
The cache can be extended on startup with env var `java.lang.Integer.IntegerCache.high `
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.
HexDecOctBin 2 hours ago [-]
What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?
DarkNova6 1 hours ago [-]
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.
spacechild1 29 minutes ago [-]
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.
Smaug123 56 minutes ago [-]
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.
jeroenhd 40 minutes ago [-]
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.
jerven 29 minutes ago [-]
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.
my-next-account 4 minutes ago [-]
It's mostly a performance question in order to adhere to Java's memory model.
Is there a writeup on why they choose to destroy the history?
jerven 23 minutes ago [-]
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.
estebank 2 hours ago [-]
It's a project years in the making.
thibaut_barrere 2 hours ago [-]
Yes, massive respect for that type of perseverance on long term, important changes.
jurgenburgen 2 hours ago [-]
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.
DarkNova6 2 hours ago [-]
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.
krzyk 2 hours ago [-]
This is incremental. This change is the smallest possible one that could work.
There are more coming in later.
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.
Do I love Spring? No. Do I prefer Typescript for my little side projects? Yes.
- Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari.
- Java has switch expressions, while JavaScript, despite its Scheme influence, does not.
- And now Java is getting value objects, while JavaScript's equivalent tuples & records proposal has been withdrawn.[0]
JavaScript was not developed as a fork of Java, but much of its basic syntax still resembles Java, so I think it's fair to compare them.
[0]: https://github.com/tc39/proposal-record-tuple
As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.
I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.
I learned this the hard way, when a C++ JNI extension I was working on accidentally overwrote the pooled value for zero, and all hell broke loose...
The cache can be extended on startup with env var `java.lang.Integer.IntegerCache.high `
https://github.com/openjdk/jdk/blob/cc278dbb8a1ca0754d584270...
Naturally, a language that properly supports value semantics does not have any of these limitations.
I don't really see why you would need specific hardware to express a type in a programming language, though.
The final singular commit is cc278db (8389219: Implement JEP 401: Value Objects (Preview), 2026-07-31) https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
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 it https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
There are other projects that depend having it in place, SIMD (vectors), reiffed generics, non nullable types.