You can find more information, including some examples, in our virtual thread JEP [1] and adoption guide [2].
We did spend some time contemplating teaching the platform about non-thread-based, i.e. asynchronous sequential composition, in the end we realised that if it walks like a thread and quacks like a thread, we might as well call it a thread.
If you read the JEP and play around with virtual threads (e.g. do asynchronous IO with CompletableFuture or blocking IO in a virtual thread and see what their exception stack traces look like and what their JFR profile looks like) you'll quickly see that the capabilities they offer were simply not attainable by asynchronous code, which is why we've spent years to teach the JVM's innermost mechanisms to be able to observe virtual threads and expose them to observability tools the same way as platform threads are (and how I know those capabilities weren't available before).
We've written and presented a significant amount of published material about virtual threads so there's not much point in recreating it here, but if you're interested, all that material is out there.
I read materials, and my opinion is that virtual threads is hyped mess which adds very little benefits (or maybe doesn't at all) in very few use cases, but will bring more complexity and fragmentation into platform:
- 95% java business spaghetti code doesn't require such scalability and fine with spawning of 10k threads on modern hardware
- in 5% left cases, 80% can be covered by executorservice and forkjoinpool
- in 1% cases which left, engineer made wrong decision in choosing JVM because of its other many performance issues
The fact that you can't bring simple code example and quality of your previous comments make me think that you not necessary understand what are you doing.
I don't know what relevant performance issues you're referring to, but if you want to learn more about concurrency and performance, I suggest you start with some of the basics of the theory behind concurrent servers: https://youtu.be/07V08SB1l8c
As I said, I've put examples and detailed explanations in a significant amount of material that's available online that will help you understand how and why user mode threads work and why we decided to add them to Java. While I can't teach concurrency and the design of the Java platform from the ground up (especially detailed mechanisms such as stack walking, JVM TI and JFR) on an individual basis on social media, I'd be happy to answer any specific questions you may have once you've familiarised yourself with the subject.
Are you aware you're talking to the guy who added virtual threads to the JVM? Disagree on design if you wish, but the idea he isn't an expert in these matters is a bit silly.
He is person on salary in oracle, which is not top tier tech company.
There are tons of virtual threads like frameworks were implemented in JVM and in other languages, looking at his github profile he has 5 years experience in working on this thread stuff, before that he worked on some bloated j2ee stuff, all of these doesn't qualify for some unconditional authority, so I judge him base on his expertise demonstrated in this discussion, which looks very weak.
