Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jvm-weekly.com

Post reply on HN
Print view View original

331–340 of 464 posts

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

#331

Post by pron »

stickfigure wrote: post #294
pron wrote: post #291

Earlier quoted context omitted.

> the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types. Then you didn't read the JEP draft (it's not an accepted JEP) carefully. It says, under "future work": Providing a mechanism in the language…

It's a proposal for a proposal, fine. Consider this my proposed feedback. I don't think this syntax is desirable as currently proposed, and that one line under "future work" is doing far too much lifting. My sincere hope is that there are people closer to the process that also feel this way, they will provide similar feedback, and the next draft will be something completely different.

Except we like delivering features by pieces, so unless your proposal is to first deliver global flags with no instance-specific control and later add more control (and I think you're not suggesting that), I don't see any difference between what you're suggesting and what that draft is suggesting. That a one-line under "future work" is doing a lot of lifting is just how we usually do it (and it's okay, people always complain, but we've tried the big-bang approach and this one just works better for us).

So consider that draft as an idea for how the site-specific nullability annotations could work rather than an idea for how nullability could work in the language in general.

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

#332

Post by DarkNova6 »

jaen wrote: post #132
DarkNova6 wrote: post #77

Earlier quoted context omitted.

C# actually has a fair amount of gotchas and Java aims to make these explicit. So where C# mostly copied C from a low level perspeCtive, the Java guys approached this high level and analyzed in detail which constraints give you what kind of benefit. So where in other languages, the struct/class taxonomy is binary, Java allows more granular control, reflection the semantics of the underlying domain. Snd as it turns ou…

Could you actually explain/exemplify any of the gotchas and what's been made better (or is this just handwaving)?

I've been let down by structs in C# repeatedly. First of all, there are no constructor guarantees and you can never fully avoid them representing an illegal state. Which, wouldn't be so bad if there was some kind of post-construction validation, but this also isn't part of the language.

This is fine if you hand-roll all your code yourself, but I often use mapping libraries to lower the code footprint and the problems resulting from schema changes are subtle and fly under the radar. This is different from classes with hard construction guarantees, which Java would offer with their "integrity by default" mantra. Where you can opt out of integrity for performance benefits (which is also part of the design).

And Nullability in C# is an absolute nightmare. The type system has completely different rules for nullable types that generalize over classes and structs and there is no generic such as a "Nullable type".

It's just lots of minor annoyances that don't form a cohesive whole.

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

#333

Post by lacerrr »

tsimionescu wrote: post #162
gf000 wrote: post #16

Earlier quoted context omitted.

> genuine breakthrough Well, it is - because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades. Sure, adding it to a new language is not hard. Adding it to Java which has primitives, generics and boxing, finding ways that seamlessly cover the differences between objects and primitives, while trying to plan for th…

Except of course they are breaking backwards compatibility, in relatively subtle ways, for anything that uses the standard library wrapper types. So every use of Integer, Boolean , etc is an opportunity for either a compilation error or a runtime bug.

Honestly, if you're relying on `new Integer(999) == new Integer(999)` to be false, you've earned your bug.

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

#334

Post by petilon »

zoogeny wrote: post #328
petilon wrote: post #323

I understand the rationale for value classes, but the implementation is flawed. What will this code print: Point a = new Point(10, 10); Point b = a; a.x = 100; System.out.println(b.x); Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design. This is a violation of the principle of unifo…

I believe that the statement `a.x = 100;` is invalid since Record types are immutable. That is, the situation you are afraid of should be impossible.

If that's true then it is a significant improvement over structs in C#.

But the distinction still matters. Value-vs-reference semantics affect equality, identity, nullability, arrays, collections, boxing, and performance.

So this is not just an implementation detail. If a language hides that distinction at the use site, it increases the burden on the reader and makes code harder to reason about.

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

#335

Post by Reason077 »

sgt wrote: post #260
ericol wrote: post #196

Earlier quoted context omitted.

> No headers per element. No pointers. No jumping around the heap. that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it. [1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...

Exactly! But AI is here to stay. Sooner or later, even comments on HN will be 100% AI generated. And we won't be here to read them - our AI agents will. /s

That’s right. Because at some point, the volume of AI-generated posts and comments on sites like Hacker News or Reddit will overwhelm the ability of humans to read them all. So the only reasonable way for humans to participate will be to have our own AI readers summarising them, and posting furiously on our behalf!

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

#336

Post by zoogeny »

petilon wrote: post #334
zoogeny wrote: post #328

Earlier quoted context omitted.

I believe that the statement `a.x = 100;` is invalid since Record types are immutable. That is, the situation you are afraid of should be impossible.

If that's true then it is a significant improvement over structs in C#. But the distinction still matters. Value-vs-reference semantics affect equality, identity, nullability, arrays, collections, boxing, and performance. So this is not just an implementation detail. If a language hides that distinction at the use site, it increases the burden on the reader and makes code harder to reason about.

[dead]

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

#337

Post by devin »

63 wrote: post #305
devin wrote: post #295

After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.

Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.

Yeah, that would be a more nuanced take. The comments I'm indirectly referring to are people who are literally unaware of these features and talk confidently as if they do not exist.

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

#338

Post by bradleyjg »

pron wrote: post #272
resonious wrote: post #104

Earlier quoted context omitted.

This is great advice and it applies to a lot more than just language features. Different architecture, deployment setups, QA approaches are all like this. It's always "approach A is no good", "but company X uses approach A and they're doing very well", "yeah but look at all of these problems they have". Maybe a fair argument but the approach B people also have their fair share of problems...

What's funny is that the only languages in the same popularity league as Java are Python and JS/TS (and possibly C and C++ if you want to extend things to more domains) yet I rarely ever hear people saying Java should be more like these languages. It's because many of the people who dislike Java also don't like any of the most popular languages (even those who like, say, Python better don't think Java should be more…

I definitely see people asking for features from c++. In part because virtually every feature is in c++.

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

#339

Post by mands »

devin wrote: post #295

After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.

Agreed - you don't get great JVM takes on HN, it's out of fashion here.

Our work uses modern Java (26 w/ preview features - mainly for StructuredConcurrency), and it's fantastic. Do not regret it one bit, and that's coming from using both Haskell and Python at previous companies.

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

#340

Post by MBCook »

petilon wrote: post #323

I understand the rationale for value classes, but the implementation is flawed. What will this code print: Point a = new Point(10, 10); Point b = a; a.x = 100; System.out.println(b.x); Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design. This is a violation of the principle of unifo…

From my read of the article line 3 is a syntax error. All fields in value types are final.

No, there’s no way to know from those four lines that will happen, but we have that problem today. If Point was a record the same thing would happen.

Post reply on HN