Thanks, Jose. I think your explanations are just at the right balance between technical and understandable. Your shorts are almost the only shorts I watch on RUclips! Please keep on that way. I also need a copy of your mug of coffee, for it seems to empty itself only at the end of your task ;-). Merci !
Thanks José for presenting this in such an easy way to understand, especially on the limitations of the system. I did read in some places that synchronized code would always be pinned to a platform thread which was detering me from investigating moving to jdk 21 to benefit from virtual threads given the fair amount of synchronized code we unfortunately have in our legacy applications. But I will now revisit that plan with the information you provided. Thanks again
wow, an absolutely masterfully extended way of saying: "cheaper threads, to better hide the complexity of asynchroneous". I was just wondering why not Promises, but Virtual Threads (with essentially non-public async framework) instead. Now i know. Thanks
If Mr. José Paumard is not an actor, maybe he should. This video is pretty funny!!! 😅 Nice to get a chance to delve into such complex content in a lighter and interesting way. Thank you, José 👏👏👏
Absolutely fantastique explainer as usual! Also so excited for Java 21 :D But as an aside, please, please, remove the white flashing transitions. It hurts my old eyes and I can think that folks with photo-sensitivity or epilepsy can have a hard time with these as well. Cheers, Niss
Thank you so much for your excellent presentation, Sir! Please give me some short explanations regarding the differences between Virtual Threads and the NIO mechanism. I appreciate your time.
Thanks. Great explanation of main topic plus extra tips. My ears satisfied when I've heard about IO in parallel computation. You said that stack is copied into the heap space. Stack is stored in RAM in stack memory. To me Java can simply keep all stacks in place, and switch between them by overriding a pointer to current stack in OS thread. Does it really need to be copied?
Clarifying question: 28:43, is this saying IO inside parallelStreams is/was always a bad idea… or is the point that it’s only a bad idea *now that Virtual Threads exist*?
Always been a bad idea. Remember, its using a thread *somehwhere* its just doing the bookkeeping for you. By default, you'll share the same thread pool w/all parallel streams in your app. That means you could starve the pool intended for CPU bound tasks (like `sum()`) while its waiting for IO
@@adambickford8720 that makes sense. Just so I’m clear, for those at or below Java 17, is the recommended alternative to use a separate, dedicated thread pool for scheduling and orchestrating blocking IO?
@@2k5325i Exactly right. Its also perfectly fine to block those I/O threads as that's the intent and it won't 'starve' other threads. It normal to have far more I/O threads than cores. Just remember each thread takes memory and overhead to manage, even if idle. If you're CPU bound, more threads than cores makes things worse, not better, virtual or not. Remember that you'll potentially want to pool connections too and now you have to multiplex threads to connections. It never ends :)
I've been working with Reactor for three years now, and while Reactor is an excellent framework, the price to pay for creating and maintaining asynchronous software is huge. This change comes not a moment too soon.
tickering reactor is a lot of fun, but not so much when comes to production and teamwork. The virtual thread makes reactor useless to me the moment I found it.
wonderful presentation jose. cant wait to start using this. Why are we not supposed to call an IO operation or say a rest api calls in parallel streams? is there any reasons?
Thank you! I/O operations in intermediate or terminal methods of streams: it's probably not working as you think. Same for parallel streams, you don't have any hand on how your data will be split, and to which point. So it gives a pretty unpredictable way of computing things. Pulling data from an I/O source: that's ok, this is what reader.lines() is doint. Don't do it in parallel though, it's useless.
Hi @Java / @JosePaumard, I want to understand the following - 1. How is it ensured that all the blocking operations invoked by any arbitrary code (excluding native method calls and synchronized blocks) from a virtual thread are managed by the Continuation framework? Have all the potential blocking points in the JDK been identified and adapted to support this? 2. Consider a third-party library that is confirmed not to use native methods or synchronized blocks. While calling it from a virtual thread, is it still necessary to manually verify that it will not accidentally block the underlying platform thread? Thanks.
No, virtual threads were created not to have the async await pattern. It solves this bad pattern in languages, where there are async methods and others not, because when you start to have a method with async it contaminates the others. Like when you use reactive patterns with Flux, RxJava, CompletableFuture..
Is it true that virtual threads (called green threads) were already present in java 1.1 but then abandoned in 1.3 as too limiting? Could you please elaborate on what was consider the limitation then and how these limitations are overcome with this new implementation?
Green threads were indeed an attempt at doing the same kind of things. But they were not working in the same way. One of the major difference was that a green thread was actually bound to a single platform thread, and could not jump from one another. There were other caveats, and in the end green threads were removed from the platform. Virtual threads are a totally new feature, with the same ideas in mind, but implemented in a complete new way.
Read my earlier post please and please help me to answer following question:"Why does Java sais that it invented something called virtual threads, when it was invented many years ago for C? How can something that is allready invented be invented again?"
@@JosePaumard Sorry for my not correctly using the english language. I am not used to it 100%. I try my best. You are right that Java can't speak :-))) What I meant was the project and or company of course. I repeated looking the video again. It is said that JDK introduced Virtual Threads. So this does not mean that they invented it. So you are right virtual threads are not an invention of Java (project/company). Thank for helping to clearify this point. In short:"Virtual threads were not invented by JAVA (project/company.) Best regards.
If my project is using java8 and upgrade to java21, will my old blocking code run in a virtual thread be pinned back to the platform thread? (old code includes old libraries like JDBC, GRPC, REST CLIENT)
One stupid question may be, What a raw implementation of creating a platform/kernel thread would like? If I want to create a platform/kernel thread without depending on Thread class how can i do it? Just curious to know if it is documented somewhere to read internals.
Does In-memory computation mean a task for CPU bound job? If so, computing some tasks with virtual thread isn't good cuz virtual thread has more overhead than planform thead. (of course virtual thread is way much better when it comes to blocking). Do I get right?
That's the job of structured concurrency. It is still in preview in 21, reason why I chose not to cover it here. You can watch how it is working on this channel: ruclips.net/video/2nOj8MKHvmw/видео.html
@JosePaumard yeah, it does seem like these frameworks do a lot of complicated stuff to decouple concurrent tasks from threads to try deal with blocking stuff, which is what virtual threads do.
Thank you .. but could you please please please mute the background music as it is distracting and irritating. The music is unnecessary for this type of content. Content itself is great but the music makes it feel like when you are studying for an exam and you hear blast of TV noise coming from the other room.Thanks again
There is no reason that your code run faster on virtual threads. In the end, it is a platform thread that executes your virtual thread. What you should run in a virtual thread is I/O operations. Then you will get better performances, because blocking is handled in a much better way than asynchronous code.
the piano is driving me crazy
There is a whole asylum of us now.
Very informative and insightful as always. Highly grateful to have been instructed by you on RUclips and other platforms.
Great to hear!
Your page becomes my number #1 source of learning Java faster. I love to always watch this channel. Thanks for all you do, Sir.
Thank you!
FInally! We can just let our threads block on IO, as God intended!!!
My first thought watching this was "oh god, no".
I liked to listen the before and after virtual threads, it makes much clear everything.
Thanks, Jose.
I think your explanations are just at the right balance between technical and understandable. Your shorts are almost the only shorts I watch on RUclips! Please keep on that way.
I also need a copy of your mug of coffee, for it seems to empty itself only at the end of your task ;-).
Merci !
Thank you Laurent!
Never heard anybody else explain in such a detailed and simple/friendly way. Congratulations!
Thanks José for presenting this in such an easy way to understand, especially on the limitations of the system. I did read in some places that synchronized code would always be pinned to a platform thread which was detering me from investigating moving to jdk 21 to benefit from virtual threads given the fair amount of synchronized code we unfortunately have in our legacy applications. But I will now revisit that plan with the information you provided. Thanks again
Thank you! Glad I could help!
Thanks José for making this video,
Really easy to understand the mechanics of Virtual Threads, how they work under the hood.
Thank you!
wow, an absolutely masterfully extended way of saying: "cheaper threads, to better hide the complexity of asynchroneous". I was just wondering why not Promises, but Virtual Threads (with essentially non-public async framework) instead. Now i know. Thanks
Awesome video. Very well structured and presented!
Glad you liked it!
Greatly and well presented. Keep up the good work Jose! We need more on this topic
Thank you! I will publish more when we have the new version of Structured Concurrency. Stay tune!
José, I am becoming addicted to your cup of Java 🙂
Very great and detailed explanations of the topic!
Thanks!
Excited to dig into this
Nothing to say except: "Awesome!"
Magnificent explanation of pure engineering art. "Project Loom" is indeed a revolutionary masterpiece. 👏👏👏
Amazing explanation...José Explaining both approaches and doing it so well with code is as always great.
Wow.. Loved your session. Super knowledgeable. Thank you very much
Perfect! Thank you, Sir!
Merci José, super intéressant !
Merci Yves!
Great Explanation !!!
Thank you!
Great Explanation ! Thank you
Thank you!
If Mr. José Paumard is not an actor, maybe he should. This video is pretty funny!!! 😅
Nice to get a chance to delve into such complex content in a lighter and interesting way.
Thank you, José 👏👏👏
Thank you, that was a great breakdown, I like to see more presentations from this guy again.
Perfect presentation ! Thank you ! Pretty that sonar don't support it yet .. hope it is coming soon.
I like when this gentleman takes a sip of his coffe!!!
Continue ton super travail José ;)
Merci ! 🙂
Absolutely fantastique explainer as usual! Also so excited for Java 21 :D
But as an aside, please, please, remove the white flashing transitions. It hurts my old eyes and I can think that folks with photo-sensitivity or epilepsy can have a hard time with these as well.
Cheers,
Niss
Thank you Niss! I wasn't aware of this problem with flashing transitions, thank you for reporting. I will change that in the next videos.
Merci Infinimenent@@JosePaumard
Always a pleasure to follow your vids ^__^
He explained it so clearly. Bravo
This is why I stick with java. The quality of people working on it is amazing.
Great explanation master
Gracias!
Awesome explanations sir....Really nicely explained in plain simple language....
Very great explanation. Emphasized and repeated the important parts. 😀
Thanks!
Oh là là, une magnifique explication! merci!
great explanations! thanks
Very clear and nice explanations. Well done !
"You're not doing I/O in your parallel streams, right?". Oh God, thankfully not. 😅 Very good video.
Thanks José!
Great solution for i/o ops.
Very great explanation! Thank you sir
Thank you for this - that coffee must have been getting cold by the end
Not quite, that's a good cup, it can keep the coffee warm for long enough 😉
Best loom explanation 👌
he holding java coffee is just 💥💥💥
Amazing feature! Thanks for the explanation too!!
Thank you so much for your excellent presentation, Sir!
Please give me some short explanations regarding the differences between Virtual Threads and the NIO mechanism.
I appreciate your time.
José thanks for this clear explanation!
Awesome video, thank you very much 😊
How virtual threads are better than non-blocking I/O (Java NIO) created 20 years ago and extensively used today?
nio requires so mich code change it mightnt worth it
Merci Beucoup
fisrt time i see you , i use to read "java le soir " blog articles !
Wow!
thx for this introduction
Your coffee makes me wants to make a cup of coffee :)
Thanks. Great explanation of main topic plus extra tips. My ears satisfied when I've heard about IO in parallel computation.
You said that stack is copied into the heap space. Stack is stored in RAM in stack memory. To me Java can simply keep all stacks in place, and switch between them by overriding a pointer to current stack in OS thread.
Does it really need to be copied?
Clarifying question: 28:43, is this saying IO inside parallelStreams is/was always a bad idea… or is the point that it’s only a bad idea *now that Virtual Threads exist*?
Always been a bad idea. Remember, its using a thread *somehwhere* its just doing the bookkeeping for you. By default, you'll share the same thread pool w/all parallel streams in your app. That means you could starve the pool intended for CPU bound tasks (like `sum()`) while its waiting for IO
@@adambickford8720 that makes sense. Just so I’m clear, for those at or below Java 17, is the recommended alternative to use a separate, dedicated thread pool for scheduling and orchestrating blocking IO?
@@2k5325i Exactly right. Its also perfectly fine to block those I/O threads as that's the intent and it won't 'starve' other threads. It normal to have far more I/O threads than cores. Just remember each thread takes memory and overhead to manage, even if idle.
If you're CPU bound, more threads than cores makes things worse, not better, virtual or not.
Remember that you'll potentially want to pool connections too and now you have to multiplex threads to connections.
It never ends :)
why dont you introduce async await instead completedfuture mess ? :D
I've been working with Reactor for three years now, and while Reactor is an excellent framework, the price to pay for creating and maintaining asynchronous software is huge. This change comes not a moment too soon.
tickering reactor is a lot of fun, but not so much when comes to production and teamwork. The virtual thread makes reactor useless to me the moment I found it.
wonderful presentation jose. cant wait to start using this. Why are we not supposed to call an IO operation or say a rest api calls in parallel streams? is there any reasons?
Thank you!
I/O operations in intermediate or terminal methods of streams: it's probably not working as you think. Same for parallel streams, you don't have any hand on how your data will be split, and to which point. So it gives a pretty unpredictable way of computing things.
Pulling data from an I/O source: that's ok, this is what reader.lines() is doint. Don't do it in parallel though, it's useless.
Hi @Java / @JosePaumard, I want to understand the following -
1. How is it ensured that all the blocking operations invoked by any arbitrary code (excluding native method calls and synchronized blocks) from a virtual thread are managed by the Continuation framework? Have all the potential blocking points in the JDK been identified and adapted to support this?
2. Consider a third-party library that is confirmed not to use native methods or synchronized blocks. While calling it from a virtual thread, is it still necessary to manually verify that it will not accidentally block the underlying platform thread?
Thanks.
Clean code, makes wonder what I have always been writing 😢
Coffee cup, that's just classy
Very nice new feature! Thanks. Is there some chance to see in Java mechanism like in C# async/await?
No, virtual threads were created not to have the async await pattern.
It solves this bad pattern in languages, where there are async methods and others not, because when you start to have a method with async it contaminates the others. Like when you use reactive patterns with Flux, RxJava, CompletableFuture..
Thanks your great talk!
so... should we worry about the platform threads are enough, how can we observe it, eg: queue size, active thread number...
good explanation
Is it true that virtual threads (called green threads) were already present in java 1.1 but then abandoned in 1.3 as too limiting? Could you please elaborate on what was consider the limitation then and how these limitations are overcome with this new implementation?
Green threads were indeed an attempt at doing the same kind of things. But they were not working in the same way. One of the major difference was that a green thread was actually bound to a single platform thread, and could not jump from one another. There were other caveats, and in the end green threads were removed from the platform.
Virtual threads are a totally new feature, with the same ideas in mind, but implemented in a complete new way.
ForkJoinTask and ForkJoinPool is tgere to do light weight concurrent Thread execution but why Virtual Threads again?
The captions on this seem to be for a different video, kinda confusing 😶
Thank you for reporting it! It should be fixed now.
can anyone explain what does "that would include the probable context switching that you will have to pay" mean at 28:12 ?
Read my earlier post please and please help me to answer following question:"Why does Java sais that it invented something called virtual threads, when it was invented many years ago for C? How can something that is allready invented be invented again?"
Sorry but I don't think Java ever said that it invented Virtual Threads. Where did you saw that?
@@JosePaumard Sorry for my not correctly using the english language. I am not used to it 100%. I try my best. You are right that Java can't speak :-))) What I meant was the project and or company of course. I repeated looking the video again. It is said that JDK introduced Virtual Threads. So this does not mean that they invented it. So you are right virtual threads are not an invention of Java (project/company). Thank for helping to clearify this point. In short:"Virtual threads were not invented by JAVA (project/company.) Best regards.
@@nejathakan5521 We agree: Java can't speak :-))) Best!
If my project is using java8 and upgrade to java21, will my old blocking code run in a virtual thread be pinned back to the platform thread? (old code includes old libraries like JDBC, GRPC, REST CLIENT)
One stupid question may be, What a raw implementation of creating a platform/kernel thread would like? If I want to create a platform/kernel thread without depending on Thread class how can i do it? Just curious to know if it is documented somewhere to read internals.
where can i get that java cup, please?
Does In-memory computation mean a task for CPU bound job? If so, computing some tasks with virtual thread isn't good cuz virtual thread has more overhead than planform thead. (of course virtual thread is way much better when it comes to blocking). Do I get right?
Yes. Virtual threads are only interesting if your task blocks.
12:49 In this mess how can i check that?
frontend with java.. why not?
Measure. Don't guess.
You had been drinking that tea for 33 mins. Wasn't that cold?
Can I have a cup of ur coffee sorry I am too excited about features
how do you launch 2 or more io ops in parallel and wait for both like when parts of your data flow fan out and fan in
That's the job of structured concurrency. It is still in preview in 21, reason why I chose not to cover it here.
You can watch how it is working on this channel: ruclips.net/video/2nOj8MKHvmw/видео.html
but this feature isnot new. it was produce in
java 19
Yes. The new thing is that it is now a final feature. And there were some updates too.
content is too good, however the piano background music is driving me crazy. Anyway thanks Jose
Hrm.. so would reactive mechanisms need to bother with all that they do? Or just use these for the blocking stuff?
Use them for the blocking stuff. And ask yourself: do you need to write your code in an async way. Maybe you don't.
@JosePaumard yeah, it does seem like these frameworks do a lot of complicated stuff to decouple concurrent tasks from threads to try deal with blocking stuff, which is what virtual threads do.
@@--Nath-- Exactly.
Thank you .. but could you please please please mute the background music as it is distracting and irritating. The music is unnecessary for this type of content. Content itself is great but the music makes it feel like when you are studying for an exam and you hear blast of TV noise coming from the other room.Thanks again
Maybe low the volume little bit or some other types of music.
How many cups of coffee have you been drinking, sir?
One. Just one, really 😄
@@JosePaumard Your presentations are amazing, sir. Keep up the good work 👍
@@VuLinhAssassinThank you!
Is any guess when Oracle will make normal modern docs site like Kotlin, JS,Python has? JavaDocs is ugly
subtitles are totally unrelated...🤣🤣
I just fixed them. Sorry for the inconvenience.
Performance vs classical threads is so disappointing. There is nearly no diff
There is no reason that your code run faster on virtual threads. In the end, it is a platform thread that executes your virtual thread. What you should run in a virtual thread is I/O operations. Then you will get better performances, because blocking is handled in a much better way than asynchronous code.
would have been nice to have a video without the music 😅
😂
Please remove background music.
Why Germans are so good at everything
Amazing talk! Really complete and comprehensive! Thank you for that.
Best ever.
Awesome explanation
Glad you think so!
obrigado José!
Good explanation as always, thanks a lot for these videos
Great video thank you
What a nice way to explain java virtual threads. 👏 Thanks Jose !
Fun fact... I once run I/O in parallel Streams !🥲