Big News from Project Valhalla - Inside Java Newscast #77

Project Valhalla's current draft proposal includes value classes, nullness markers (aka null-restricted types) for identity and value classes, as well as an extended construction protocol for null-restricted fields. Taken together this would allow #Java developers to create types with much of the power of regular reference types but performance close to that of primitives - hence the slogan "codes like a class, works like an int". At #JVMLS 2024, project lead Brian Goetz presented the current state of Project Valhalla - in this video I summarize the proposed changes to the programming model.

Links:

~~~ Chapters ~~~

0:00 Intro
1:03 Polar Opposites
2:16 Identity
4:17 Nullability
7:07 Memory Layout
9:04 Remaining Differences

Tags: #Java #OpenJDK #Performance

[nipafx]

At the end, there, I kinda teased that I would give you my estimates for when we're going to see these changes land. The people working on the JDK are really adverse to publishing any estimations, so everybody ends up making their own. I don't have any inside information, either, but I follow these processes quite closely and so I think my guesses are better than most. But not on Valhalla. I've been guessing "it's around the corner" for years now and I've been wrong every time. It's my "year of Linux on the desktop" - highly expected, well-deserved, but never quite there.

So as much as I want to tell that I think we have good chances to see JEP 401 in 2025, at this point I really don't know whether that's any more than wishful thinking. I am pretty confident that that's the first or at least one of the first preview features we'll see out of Valhalla, though, probably followed by JEP 402 before maybe null-restriction starts showing up.

While I have you here: I highly recommend to watch Brian's talk! (Link in the description.) I feel like just listening to the guy talk about design, temporarily raises my IQ by 20 points. 😂

[Lucario]

I watched the entire talk, but thanks for this compressed version!

[davidhsv]

Can't wait to use this to write leetcodes code that you can actually read, and has the same performance as using primitives

[lukeusherwood]

Love listening to Brian & did watch that to the end... so need to pull you up on one detail ;-) The elephant exposed in video chapter "Flattening & Tearing Values" was that only classes up to 64-bits will automatically flatten, with an extra (to be determined) specification required to opt-in for larger objects to flatten. (So: 1 more bullet point needed here around 8:50.) Still as you say - I'm also looking forward to the improved type / nullability aspects, not only the memory/performance bits.

[Lucario]

Could you do a video about the relationship between records and value classes and the potential of using them together?
I think I've got a pretty good grasp of their differences, but would like to see how they expand each other in various use cases.

[顾清l]

I'd like to ask why about nullable, why two identifiers were added, wouldn't it be simpler to just add an identifier for non-null and have the old type identifier considered nullable?

[TheBigLou]

4:38 I personally don't like that a binary operator for inversion (true becomes false and false becomes true) could get a double-meaning where something produces an error if you come across a null. I'd Prefer something like NotNull<String> or String::Something or String{...} like the withers, but for classes instead of keywords - that could even enable an allow/disallow list, not limited to a forbidden null. And the other thing: "String?" (possible nulls) sounds pretty much exactly the same as "String" (with possible nulls) to me :/ Maybe I'm missing something here. But generally, if you want to have no nulls, why not just make it final, so it requires an explicit assignment at one point- or which will ALWAYS return a value without any exception. Maybe its just me but I _really_ don't like the Kotlin style (e.g. that ambiguous operator double-usage). Kotlin feels alien and convention-breaking in many areas compared to Java to me. I had to write Kotlin for a few years at work and it teached me to never ever accept and job anymore where I'd have to write Kotlin. It felt like tying knots in my muscle- and pattern-memory for C-based languages (like Java). But again, maybe thats just me. I hope the Java-Wardens will make the right decisions and improve on what can be learned from others. Long live Java! ☕

Edit: Corrected some spelling and grammar imperfection.

[RobertMarkBram]

My, my, my, my Exceptions hit me, so hard!

[VuLinhAssassin]

Hi Nicholai, can we expect all or most of them to be generally available next LTS (25)?

[michaelschneider]

Don't know when we will finally get value types, but I'm pretty sure, it will be still before we get string interpolation.

[emmanuelzakaryan]

plz give us null safety as in Kotlin and we'll be happy about that

[shine]

so we can expect more performance right ? To which extent ? Tx

[Rope]

Guess I'm one of the few that actually watched it till the end 😆

[reactiveland]

? And ! Sacre me. Java taste is not those strange marks. Java is better stay expressive

[unbekannter_Nutzer]

@5:55 A reasonable value for an uninitialized String? Well, val - how about the empty String ""?

[ennioVisco]

@nipafx please can we say referential transparent instead of identity? Identity has a completely different intuitive meaning and I believe this creates more confusion than helps

[Ilumar]

Big dislike from me :) for the clickbaity title. Can't put a title like that when people have been waiting for this feature such a long time and then just do a recap of Brian's talk. Other than that keep up the good work :)

[danthest]

Nicolai really wanted the 10 minutes so he is talking fast 😂

[IvanToshkov]

You know, Turing machines contain all the essentials and nothing else. Perhaps we should all just program them instead.

[mconradie]

One day.... Java will have the features that C# has had for decades. Yay!