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. 😂
Thank you for watching the video despite knowing the talk. 😊 It wasn't easy to position the Newscast, knowing so many people watched parts of the talk, and I hoped that a good summary would appeal even to those who watched most of what Brian said at JVMLS. It looks like that plan at least didn't fail entirely. 😁
@@nipafx It's definitely easier to recommend a 10min video to my uninitiated coworkers than suggesting they spend an hour with a topic they've never heard of. Maybe this can get them to share my excitement about Valhalla.
@@Lucario2405 That would be great! Although the video kind of assumes people are already excited about Valhalla as it doesn't get to the big payoff before minute 7:07. 🙈
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.
Not quite. This threshold is hardware-dependent, and some newer chips are already claiming faster 128-bit atomics. And of course, because layout is done at runtime, we can take the actual processor capabilities into account when doing layout.
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.
Yeah, that's a good idea. I think such practical advise best builds off of practical experience, though, and would also land best when both features are readily available (at least as preview). Remind me in 2034 when that happened. 😂
aren't records value classes with some auto syntax sugar!! I always thought records were a stop gap mistake and should have never been added to the language. Unless I missed something.
@@curio78 They have some superficial similarities but the trade-offs are very different: Records let you trade API control for transparency, which enables record patterns, sane serialization, withers (th-cam.com/video/tcihVdB7oU8/w-d-xo.html), reduced boilerplate, and more. Value classes let you trade identity for not-having-to-deal-with-identity and performance. Neither is a stopgap for the other. That said, many records will want to become value records because types that don't control over their API also often don't need identity.
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?
I think the idea is that 1) non-null is null safe, 2) nullable is also safe in that the compiler will check to see if you access it safely (perform null check whenever accessing it). While default is similar to 2 in that it allows nulls but the java compiler does not enforce that null check must be performed before access, instead a runtime error is thrown just as it happens today.
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 :)
It's a tightrope. To reach the most people, I decided to go with the more engaging thumbnail/title and then clarify in the first few seconds what to expect. But I was sure that not everybody would be happy with that decision and I accept your criticism.
I wonder when Java would start dominating in in terms of UI development, swing outdated JavaFx when building with it, you start seeing bugs that doesn't actually make sense 😢
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 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 Optional.ofNullable(nullable).orElse("value") 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.
Oh and "Class?" can (on the first look) be confused with inline-if like booleanValue ? "yes" : "no"; BooleanValue? yes = no(); // method no() returns a BooleanValue.
In Scala, null is of type Null and by default Null is a subtype of all objects. Which allows you for example to assign a null to a variable of type String: val toto: String = null We also have union types, which looks like: val toto: Cat | Dog = new Cat() (You would have to switch on it to access non common methods) Now with a compiler flag you can disable the implicit inheritance of Null by all types. Which makes null unassignable to a String if we take the above first example). Now with union you can do the following to accept nulls: val toto: String | Null = null That's the syntax that came naturally. I find it elegant.
100% many PL have this problem and some of them are consider very difficult C/C++ int* pt - pointer, int** pt - double pointer go figure out what is what and how it behave in 1000 lines of text on 4K monitor Single characters have multi-meaning unless it is very recognizable character like $ and they are very rare. + in java ? is already using in generics and for most developers generics is hard topic More characters or less characters can be translate into - 'I need to use my brain in order to figure out' vs 'I just read and it easy to understand with turn my brain on'
@@cptfwiffo Perl is very different, it's more like Python, it's interpreted, it's not typed. Scala is strongly typed, it benefits from all the JVM improvements, GraalVM... It compiles to JS or Wasm. It's not comparable.
@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
I don't agree. The idea being expressed here matches my intuitive meaning of "identity". In any case, referential transparency is a syntactic concept (about substituting one expression for another) while identity is a semantic one. It's a difference analogous to that between the declared type of a field versus the runtime class of an object.
@@prdoyle I don't know what notion you have of syntax but it's definitely wrong if you think that it's a "syntactic concept". Does == not comply with your intuitive meaning of identity? Would you intuitively say primitive types don't have identity? If so, I'm really curious about how you end up there 😂
And yet, C# will still be missing all the features java has. Like proper class based enums, virtual threads, concurrency without the coloring problem, and standardized stream methods that are named after actual functional concepts instead of SQL..
It took them just 20 years (after .NET) to make draft proposal. Let's hope it'll take them no more than 10y to implement it as experimental feature. Who knows, maybe we'll get value types by 2050?🤔
What they are doing is pioneering. This feature has to work with so much, including the JVM’s incredible optimisations. Java doesn’t just throw in features like .NET does. Each feature is exhaustively designed and evaluated for readability of code, ease of use for all skill levels, and compatibility with decades of existing source and compiled code. These features are what Java has changed the software world.
@@sjzara I agree with carefully rolling out features. But once you go over the decade mark (like for Valhalla) instead of years, it is inevitable that you are falling behind. People have been moving off Java because other languages have these features. And it shows: in the Java 23 release live stream they had a section about telling people Java is still relevant. Yet the highlight feature of Java 23 is Markdown in JavaDoc? Is this a joke?
@@joan38 @sjzara is right in a way. If you've worked with C# structs before or recently you'll see they still have limitations either at runtime or syntactically. For example in C# you have to specifically tell if you passing by ref for a mutable struct or with in keyword for an immutable(readonly) struct while in java the runtime will handle that. Add to that that you can't pass structs by reference in async functions because of some technical thing I won't get into here while I'm guessing java won't have this issue for functions inside virtual threads, the runtime will handle that as well. Another thing would be that java value classes will deconstruct into it's parts and the runtime will handle them in a structure of array kind of way while in C# you would explicitly have to structure of arrays instead of array of structure. There are innovations to what Java is doing and seeing that currently java's performance is close to C++/Rust/C# especially when multithreading is involved when value classes will be released it will mind blowing how easy it will be to write performant code easily and naturally by respecting idiomatic Java while in other languages you still have to know how the relation between registers, ram, memory access in general is in order to have performant code. That's my 2 cents but yeah it's taking too long and the frustration is real especially if you're one of the people that want to use java for other stuff other than backend dev like game development. I for one have moved on to a other language for game dev but hopefully java will get value types and true generic before I'm old and wrinkly :)
are you sure you actually need that functionality, keep it simple, actually int works always like an Integer class, or is translated to be such. as it should be. the simpler the language, the more power it has. you are on purpose bloating the language feature space. ask yourself if you really really need it. if not then dont add bloat-ware. commercial entities usually do that. focus keeping the language in essentials only. yep barebones. no instead condense the language to its essentials. yep prune non-required features. yes with harsh hand. why is assembler so powerful, and useful, because it only has limited amount of features, ie direct instructions. its not worth going high level if your complexity also goes up. yes you just nullified the whole purpose of a high level language. keep it simple. if you make the programming harder than with asm, you lost your goal. features space must be more manageable than with asm. ie small-ish. condensed simple. one feature should be able to express multiple purposes and features, without needing to add separate features. feature creep is harming instead of benefitting, even if you could potentially do something with the extra feature. you should make java core as the language, and others added as imports. make sure your are very certain what is in the java core. otherwise the core language will become unusable mess. keep user libraries away from the java core language. you can already use static class member ints directly like a c/c++ struct. why would you add duplicate functionality. you have been doing that recently. whatever you want to achieve with that value complexity, you can always do with the static member fields in normal identified classes. you have a reference identity to the flat ints array of the class. arrays are already flat. also you can make the static member ints in the class flat. compiler optimization, not user more features required. I mean class member ints with the static, similar to static methods inside a class. class identity does not take much to store, ie one reference pointer. dont try to optimize in wrong places.
Why do you care? Java isn't for those that want to get the last 1% of perfomance out of a system. You're talking about a language that has a GC thus your rant doesn't really make sense. If you want a low level lang, Java isn't the lang for you. Also complexity is way more complex than just the amount of features. Sometimes complexity makes solutions simpler, sometimes a more complex model makes descriping what you want to say actualy easier. Look at Math, when I learn math in school the teachers were always afraid of showing stuff that was "too complex". Yet in reality the oversimplification made it even more complex, as you know already you will have to learn it properly anyway. Reality is complex, stop trying to pretend that everything that's complex is stupid, otherwise why would we exist?
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. 😂
For a moment(looking at title) I thought JDK 24 is getting Valhalla :)
Bring the low memory usage, I hope lilliput+leyden+valhalla can reduce java memory usage by ~50%
I watched the entire talk, but thanks for this compressed version!
Thank you for watching the video despite knowing the talk. 😊 It wasn't easy to position the Newscast, knowing so many people watched parts of the talk, and I hoped that a good summary would appeal even to those who watched most of what Brian said at JVMLS. It looks like that plan at least didn't fail entirely. 😁
@@nipafx It's definitely easier to recommend a 10min video to my uninitiated coworkers than suggesting they spend an hour with a topic they've never heard of.
Maybe this can get them to share my excitement about Valhalla.
@@Lucario2405 That would be great! Although the video kind of assumes people are already excited about Valhalla as it doesn't get to the big payoff before minute 7:07. 🙈
Can't wait to use this to write leetcodes code that you can actually read, and has the same performance as using primitives
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.
Not quite. This threshold is hardware-dependent, and some newer chips are already claiming faster 128-bit atomics. And of course, because layout is done at runtime, we can take the actual processor capabilities into account when doing layout.
Thanks Brian...Happy to see those comments wrt 128bit atomics
My, my, my, my Exceptions hit me, so hard!
Great summary Nicolai...
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.
Yeah, that's a good idea. I think such practical advise best builds off of practical experience, though, and would also land best when both features are readily available (at least as preview). Remind me in 2034 when that happened. 😂
aren't records value classes with some auto syntax sugar!! I always thought records were a stop gap mistake and should have never been added to the language. Unless I missed something.
@@curio78 They have some superficial similarities but the trade-offs are very different: Records let you trade API control for transparency, which enables record patterns, sane serialization, withers (th-cam.com/video/tcihVdB7oU8/w-d-xo.html), reduced boilerplate, and more. Value classes let you trade identity for not-having-to-deal-with-identity and performance. Neither is a stopgap for the other.
That said, many records will want to become value records because types that don't control over their API also often don't need identity.
Its a big change to Java world
Don't know when we will finally get value types, but I'm pretty sure, it will be still before we get string interpolation.
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?
I think the idea is that 1) non-null is null safe, 2) nullable is also safe in that the compiler will check to see if you access it safely (perform null check whenever accessing it). While default is similar to 2 in that it allows nulls but the java compiler does not enforce that null check must be performed before access, instead a runtime error is thrown just as it happens today.
When will we get Valhalla incubator?
See pinned comment.
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 :)
It's a tightrope. To reach the most people, I decided to go with the more engaging thumbnail/title and then clarify in the first few seconds what to expect. But I was sure that not everybody would be happy with that decision and I accept your criticism.
@@nipafx It's fine, not that big of a deal, no dislike given 😋. Keep up the good work informing the java community
I agree. I first thought this was an announcement of a timetable of Valhalla release.
@@sjzara same 😢
a title that just spiked the frustration level of the wait.
Hi Nicholai, can we expect all or most of them to be generally available next LTS (25)?
No. We'd be lucky to even get the `value` keyword (JEP 401) as a preview by JDK 25. For a more detailed non-estimate, see the pinned comment.
I love how they are really taking all the features from Kotlin 😂
I wonder when Java would start dominating in in terms of UI development, swing outdated JavaFx when building with it, you start seeing bugs that doesn't actually make sense 😢
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 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 Optional.ofNullable(nullable).orElse("value") 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.
Oh and "Class?" can (on the first look) be confused with inline-if like booleanValue ? "yes" : "no"; BooleanValue? yes = no(); // method no() returns a BooleanValue.
In Scala, null is of type Null and by default Null is a subtype of all objects. Which allows you for example to assign a null to a variable of type String:
val toto: String = null
We also have union types, which looks like:
val toto: Cat | Dog = new Cat()
(You would have to switch on it to access non common methods)
Now with a compiler flag you can disable the implicit inheritance of Null by all types. Which makes null unassignable to a String if we take the above first example).
Now with union you can do the following to accept nulls:
val toto: String | Null = null
That's the syntax that came naturally. I find it elegant.
100%
many PL have this problem and some of them are consider very difficult
C/C++
int* pt - pointer, int** pt - double pointer
go figure out what is what and how it behave in 1000 lines of text on 4K monitor
Single characters have multi-meaning unless it is very recognizable character like $ and they are very rare.
+ in java ? is already using in generics and for most developers generics is hard topic
More characters or less characters can be translate into - 'I need to use my brain in order to figure out' vs 'I just read and it easy to understand with turn my brain on'
@@joan38the moment you say scala I'll tell you that perl is better, more successful and readable. 😂
@@cptfwiffo Perl is very different, it's more like Python, it's interpreted, it's not typed. Scala is strongly typed, it benefits from all the JVM improvements, GraalVM... It compiles to JS or Wasm.
It's not comparable.
Guess I'm one of the few that actually watched it till the end 😆
all I want to know is which jdk version are we seeing this? because 8 years.. and counting. so is it 1 year or 8 more years?
so we can expect more performance right ? To which extent ? Tx
Background is Kotlin color😄
@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
I don't agree. The idea being expressed here matches my intuitive meaning of "identity". In any case, referential transparency is a syntactic concept (about substituting one expression for another) while identity is a semantic one. It's a difference analogous to that between the declared type of a field versus the runtime class of an object.
@@prdoyle I don't know what notion you have of syntax but it's definitely wrong if you think that it's a "syntactic concept". Does == not comply with your intuitive meaning of identity? Would you intuitively say primitive types don't have identity? If so, I'm really curious about how you end up there 😂
Nicolai really wanted the 10 minutes so he is talking fast 😂
Guilty as charged. 😂
? And ! Sacre me. Java taste is not those strange marks. Java is better stay expressive
@5:55 A reasonable value for an uninitialized String? Well, val - how about the empty String ""?
You know, Turing machines contain all the essentials and nothing else. Perhaps we should all just program them instead.
Turing machines have infinite memory which makes them hard to build.
@@peterkerj7357 Great way to miss the point, which is about about language evolution.
@@IvanToshkov Thanks.
hi
This guy is not a nerd,dislike
I know I'm too handsome and eloquent to fit the stereotype 😉, but trust me, I am: th-cam.com/video/SIJZn2MP6OI/w-d-xo.html
One day.... Java will have the features that C# has had for decades. Yay!
lol sure but C# did it wrong and made it mutable.
And yet, C# will still be missing all the features java has.
Like proper class based enums, virtual threads, concurrency without the coloring problem, and standardized stream methods that are named after actual functional concepts instead of SQL..
It took them just 20 years (after .NET) to make draft proposal. Let's hope it'll take them no more than 10y to implement it as experimental feature. Who knows, maybe we'll get value types by 2050?🤔
What they are doing is pioneering. This feature has to work with so much, including the JVM’s incredible optimisations. Java doesn’t just throw in features like .NET does. Each feature is exhaustively designed and evaluated for readability of code, ease of use for all skill levels, and compatibility with decades of existing source and compiled code. These features are what Java has changed the software world.
@@sjzara I agree with carefully rolling out features. But once you go over the decade mark (like for Valhalla) instead of years, it is inevitable that you are falling behind. People have been moving off Java because other languages have these features. And it shows: in the Java 23 release live stream they had a section about telling people Java is still relevant. Yet the highlight feature of Java 23 is Markdown in JavaDoc? Is this a joke?
@@joan38 @sjzara is right in a way. If you've worked with C# structs before or recently you'll see they still have limitations either at runtime or syntactically. For example in C# you have to specifically tell if you passing by ref for a mutable struct or with in keyword for an immutable(readonly) struct while in java the runtime will handle that. Add to that that you can't pass structs by reference in async functions because of some technical thing I won't get into here while I'm guessing java won't have this issue for functions inside virtual threads, the runtime will handle that as well. Another thing would be that java value classes will deconstruct into it's parts and the runtime will handle them in a structure of array kind of way while in C# you would explicitly have to structure of arrays instead of array of structure. There are innovations to what Java is doing and seeing that currently java's performance is close to C++/Rust/C# especially when multithreading is involved when value classes will be released it will mind blowing how easy it will be to write performant code easily and naturally by respecting idiomatic Java while in other languages you still have to know how the relation between registers, ram, memory access in general is in order to have performant code. That's my 2 cents but yeah it's taking too long and the frustration is real especially if you're one of the people that want to use java for other stuff other than backend dev like game development. I for one have moved on to a other language for game dev but hopefully java will get value types and true generic before I'm old and wrinkly :)
are you sure you actually need that functionality, keep it simple, actually int works always like an Integer class, or is translated to be such. as it should be. the simpler the language, the more power it has. you are on purpose bloating the language feature space. ask yourself if you really really need it. if not then dont add bloat-ware. commercial entities usually do that. focus keeping the language in essentials only. yep barebones. no instead condense the language to its essentials. yep prune non-required features. yes with harsh hand. why is assembler so powerful, and useful, because it only has limited amount of features, ie direct instructions. its not worth going high level if your complexity also goes up. yes you just nullified the whole purpose of a high level language. keep it simple. if you make the programming harder than with asm, you lost your goal. features space must be more manageable than with asm. ie small-ish. condensed simple. one feature should be able to express multiple purposes and features, without needing to add separate features. feature creep is harming instead of benefitting, even if you could potentially do something with the extra feature. you should make java core as the language, and others added as imports. make sure your are very certain what is in the java core. otherwise the core language will become unusable mess. keep user libraries away from the java core language. you can already use static class member ints directly like a c/c++ struct. why would you add duplicate functionality. you have been doing that recently. whatever you want to achieve with that value complexity, you can always do with the static member fields in normal identified classes. you have a reference identity to the flat ints array of the class. arrays are already flat. also you can make the static member ints in the class flat. compiler optimization, not user more features required. I mean class member ints with the static, similar to static methods inside a class. class identity does not take much to store, ie one reference pointer. dont try to optimize in wrong places.
Why do you care? Java isn't for those that want to get the last 1% of perfomance out of a system. You're talking about a language that has a GC thus your rant doesn't really make sense. If you want a low level lang, Java isn't the lang for you. Also complexity is way more complex than just the amount of features. Sometimes complexity makes solutions simpler, sometimes a more complex model makes descriping what you want to say actualy easier.
Look at Math, when I learn math in school the teachers were always afraid of showing stuff that was "too complex". Yet in reality the oversimplification made it even more complex, as you know already you will have to learn it properly anyway.
Reality is complex, stop trying to pretend that everything that's complex is stupid, otherwise why would we exist?
@@Tobiasliese I did not talk about performance of executable code, I talk about performance of the programmer, ie easiness of the language.
@@Tobiasliese you can be smart, otherwise you would be not smart. all the time. keep it simple.
@@Tobiasliese everything complex is stupid.
@@Tobiasliese its especially stupid when you make thing complex on purpose, did I need to pay you for something, good.