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

291–300 of 464 posts

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

#291

Post by pron »

stickfigure wrote: post #284
pron wrote: post #126

Earlier quoted context omitted.

I didn't say nullability is orthogonal to value types; I said it was orthogonal to the two-projections world, which is what that text in the article was about rather than nullability. As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best te…

> More generally than just Java, nullability is often a property not of a type but of a variable I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the…

> 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 to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.

In other words, the draft already incorporates your point, but JEPs (both drafts and actual JEPs) follow the pattern we've found to work so well, that features are best delivered piecemeal rather than in a big bang.

Having said that, I don't know the current plans for this matter, as that document is only in Draft status, so saying it's good or bad is pointless, as it's not even a proposal yet, just something being explored.

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

#292

Post by tadfisher »

joe_mwangi wrote: post #239
DarkNova6 wrote: post #3

You could probably a whole tech thriller on the evolution on Value Types in Java. I’ve been reading the mailing lists and watched all videos on the topic and it is truly inspiring how much they managed to consolidate the design to something that always looked like java. But while also going far deeper in granularity and understanding what it even means to be a value type and what optimizations can be done where

And the only syntax change is adding 'value'.

There will be null-restriction type modifiers later on (e.g. declaring a variable as "Integer! foo")

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

#293

Post by ptx »

revetkn wrote: post #229
ptx wrote: post #219

Earlier quoted context omitted.

What's wrong with what .NET did with threads? Having async tasks sharing the GUI thread seems like a nice feature. Will we be able to use virtual threads and structured concurrency with Swing, e.g. to wait for a background task in an event listener?

Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below): An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that asyn…

So does Java provide an API for continuations or just the virtual threads hidden behind the threading API? You can't use threads to wait for something on the UI thread (which is why e.g. SwingWorker exists), but you can with await.

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

#294

Post by stickfigure »

pron wrote: post #291
stickfigure wrote: post #284

Earlier quoted context omitted.

> More generally than just Java, nullability is often a property not of a type but of a variable I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the…

> 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.

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

#295

Post by devin »

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.

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

#297

Post by 12_throw_away »

rayiner wrote: post #275
wongarsu wrote: post #274

Earlier quoted context omitted.

I learned that exact style of writing in a marketing workshop, pre-AI. It's effective, satisfying, and a random third thing I can't be bothered to come up with right now. As a proportion of all easily crawled text on the internet, a lot of it will be random marketing copy. That influenced the writing style of early AIs, and since then everyone has trained at least partially on transcripts from every other AI chatbot

Oh my god did we inadvertently train AIs on idiotspeak.

> did we inadvertently train AIs on idiotspeak.

Nope! That is - training on lowest-common-denominator, low-signal high-noise "idiotspeak" was not at all inadvertent.

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

#298

Post by pjmlp »

Rohansi wrote: post #263
pjmlp wrote: post #205

Earlier quoted context omitted.

That was the original motivation yes, although they acknowledged later that the weaker type system from Go required redesigning the data structures anyway. And as proven in the recent announcement, they had to rewrite parcel from C++ into Go, as they didn't found a comparable library in Go ecosystem. There is also another interview, where again they mention having used AI as tool for code rewriting as well. Also to n…

They said the prototyped in a few languages before settling on Go. Based on what you said it sounds like they didn't do a great job at that and stuck with their decision anyway. > Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one. It's been working fine for a few years now. The only problem I know is there i…

Yes, see BUILD 2025 talk for example, the section on "extreme refactoring" regarding the ASTs,

https://youtu.be/UJfF3-13aFo?t=1453

As for the AOT part, one would expect that being all Microsoft, they could work together to fix whatever were the issues with Native AOT.

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

#299

Post by Groxx »

WD-42 wrote: post #290
Groxx wrote: post #217

Earlier quoted context omitted.

I'm confused about the 2008 Bloomberg article image in the first slot... right after implying the effort started in 2014. With nothing mentioning anything in there. Is there a way we can request a "flag as AI garbage" downvote for articles? Or should we just flag them?

I thought this was an ad bugging out. I use an adblocker. Very confusing.

I initially took it for an ad too, and just didn't bother looking at it. Then I noticed it was oddly small, and the more I looked the stranger it got.

It adds a fair bit to that "did anyone proof-read this? pretty obviously no?" vibe.

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

#300

Post by kuhsaft »

pregnenolone wrote: post #243
kuhsaft wrote: post #214

Earlier quoted context omitted.

I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java. Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users. Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the…

> Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM. The creator of Scala disagrees: https://youtu.be/Xn_YpUtXWT4?t=850

Not necessarily. You can ignore the reified generic system in the CLR and monomorphize it in the CIL output for your language. Debugging for users is usually a nightmare though due to the monomorphization. The benefit of a type-erased runtime is the interop between the languages built on the runtime.

The monomorphization of CLR generics is what NativeAOT does, though it doesn't support some C# features.

TypeScript is essentially C#, but with type-erasure and lacking the low-level struct & pass-by-reference features.

I do think the C#/CLR struct implementation is better though.

Post reply on HN