Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28 • Hacker News Board

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#461

Post by drzaiusx11 » Tue, Jun 23, 2026, 1:45 PM UTC

Zardoz84 wrote: post #151

drzaiusx11 wrote: post #125

Earlier quoted context omitted.

I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotli…

Type inference was on DLang far before that Kotlin even existed. The only difference it's that reuses "auto" keyword.

not claiming kotlin invented anything, just that after kotlin adopts something and it turns out to be useful, java will come along in a few years and implement it (or avoid it, depending on how it goes)

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#462

Post by DarkNova6 » Wed, Jun 24, 2026, 2:53 PM UTC

kuhsaft wrote: post #418

DarkNova6 wrote: post #415

Earlier quoted context omitted.

This is what makes the nuances of Valhalla's Value types so compelling. The idea are granular structs with "Integrity by default", where you can selectively give up constraints on class design to get performance characteristics. Structs in most languages simply bunch a couple constraints together to get another set of performance benefits, but there's no law stating that they couldn't be singled out. In the design of…

Imo #4 is why it’s not that useful. If the data is larger than an atomic read/write op the data isn’t flattened and it’s a regular object with value equality and immutability. You have to opt into force flattening, and then it’s the same as a struct, except it’s still heap allocated without escape analysis. You still have to implement synchronization to prevent tearing. Static code analysis can give you a warning for…

Thanks, I'm always happy to learn more about .net and the CLR.

Regarding #4, is this actually a done deal? I haven't dug into the JVM specifics, but I thought they would avoid allocating objects. And for now they just want to get the model right, while continue to optimize as time moves on. I think that's the right approach.

I actually see this way less critical because if you truly have performance-critical usage of structs, you know what you are doing. And if you know what you are doing, you will know about opting-in.

And for everything else? I think it's nice to have a range of benefits that come from having a value type without handing a gun to a monkey. Because the feature will be misused by people that don't know about tearing, thinking "value" is a free performance upgrade. And I do believe that it is the right mental model to reason about it.

I just don't see the huge issue. If the CLR has a way to provide atomic access to non-tearable structs, surely the JVM can too? We are talking CPU instructions here after all. Or am I missing something?

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#463

Post by joe_mwangi » Fri, Jun 26, 2026, 9:07 AM UTC

Dylan16807 wrote: post #383

joe_mwangi wrote: post #311

Earlier quoted context omitted.

> yet But up the comment section, someone thinks they won't be there 'in the future'

The comment that says it won't be there in the near future? That's seems like a reasonable claim to me. And a promise to eventually fix a busted implementation doesn't undo it being busted for a significant amount of time.

Better late than never.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#464

Post by geokon » Mon, Jun 29, 2026, 1:02 AM UTC

pron wrote: post #398

geokon wrote: post #353

Earlier quoted context omitted.

Where do you find more nuanced discussions?

I don't think the issue is nuance. The issue is what people enjoy talking about. E.g. here's what the industry probably looks like in terms of how many people work in different languages: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... Now compare that to the languages most frequently talked about on HN. The stuff on HN isn't a reflection of the industry, just like Silicon Valley doesn't produce most…

Ah okay. That's a good insight! and something to keep in mind. There is a reality distortion lens to it all in the end. As you say, people want to explore the frontier of technology