TDT - Test Driven Tutorial was born. Also, are there any downsides of using virtual threads inside Spring since we have to manually enable them @46:20? I assumed they would be automatically enabled. Since they are not does it means that enabling them is not always the best idea?
I worry about sealed types; Library creators will use it and it will no longer be possible to create a MyXxxx extends Xxxx to fix them. Final is already a problem, but in that case I can at least (in some cases) create a copy of the entire class. Records are very nice for tuplets, like Size, Point, Color, but are a terrible idea for anything with more values, or if you need to change anything. Let's hope we can get rid of getters and setters on regular classes (without lombok) in a later version
For many (most) Java developers out there, the reactive model is hard to read, understand, use and debug. It is what it is, Flux, Mono - The API is not intuitive at all for long time Java developers as well as junior developers fresh from university. That and the fact that performance and resource advantages in reality are often neglectable means that adoption is still very low and it gets even more complicated if you add blocking legacy code into the equation. I would say that virtual threads are a more intuitive Java-way to solve the problem (you can argue about better or worse) and you don't need to change all your code and use that reactive API and care about blocking and nonblocking stuff, you "just" replace the Executor because Loom took care to retrofit all the blocking code in the JDK to be virtual-thread-aware. There is some stuff (e.g. synchronized methods pinning the virtual thread) where you have to be careful and find solutions (e.g. using ReentrantLock), but overall it is much easier to use (because transparent) and will be adopted very fast compared to the reactive model with significant impact on performance and resources. I've seen a paper, where the virtual thread model also outperformed the reactive model, but you have to be careful with any performance comparison anyways because one line of code can make a giant difference. But random educated guess: virtual threads are the deathblow to mass-adoption of reactive in Java. It has it's value in stream processing, but for most use-cases the transparent use of virtual threads will be the go-to solution.
still no one wants to use Scala after 15 years later except the minority group keeps whining: I am better than you! I know better than you!. But really no one cares because Scala is not revelant
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
3:50 - Multiline String
5:19 - Record
7:33 - Enhanced Switch
11:50 - Sealed Types
18:46 - Next Level Pattern Matching
23:29 - Improved mathematics
25:37 - Future state
27:57 - AutoCloseable HTTP Client
29:50 - String Enhancements
32:00 - Sequenced Collections
35:53 - Virtual Threads and Project Loom
The hype finally reached the Java ecosystem.
On assertion the first argument is the expected and the second is the actual value.
Besides that very nice 👍🏻
Excellent content, thanks!
excelent! Thank you! 👍🏻☕️
TDT - Test Driven Tutorial was born.
Also, are there any downsides of using virtual threads inside Spring since we have to manually enable them @46:20? I assumed they would be automatically enabled. Since they are not does it means that enabling them is not always the best idea?
Maybe since spring boot 3.x is compatible with java 17 it won't be enabled by default until spring boot 4.x?
excellent intro
great video, especially introduction!
if you could add timecodes to all features listed ---> I will be your best fan!
0:00 Introduction
3:45 Multiline Strings (Java 17)
5:14 Records
7:26 Enhanced switch statement
11:41 Sealed Types (Java 17)
18:38 Records with Sealed Types
23:29 Math enhancements
25:38 Future
27:57 Http with Future
29:48 Character.isEmoji() and StringBuilder's repeat method
32:00 SequencedCollection
35:54 Project Loom and Virtual Threads
@@larsroe5811 Thanks Brother!
love u josh ❤
La mejor intro 😂
Josh, get a professional microphone please.
I worry about sealed types; Library creators will use it and it will no longer be possible to create a MyXxxx extends Xxxx to fix them.
Final is already a problem, but in that case I can at least (in some cases) create a copy of the entire class.
Records are very nice for tuplets, like Size, Point, Color, but are a terrible idea for anything with more values, or if you need to change anything. Let's hope we can get rid of getters and setters on regular classes (without lombok) in a later version
How is the reactive system different from Virtual Threads now?
For many (most) Java developers out there, the reactive model is hard to read, understand, use and debug. It is what it is, Flux, Mono - The API is not intuitive at all for long time Java developers as well as junior developers fresh from university. That and the fact that performance and resource advantages in reality are often neglectable means that adoption is still very low and it gets even more complicated if you add blocking legacy code into the equation.
I would say that virtual threads are a more intuitive Java-way to solve the problem (you can argue about better or worse) and you don't need to change all your code and use that reactive API and care about blocking and nonblocking stuff, you "just" replace the Executor because Loom took care to retrofit all the blocking code in the JDK to be virtual-thread-aware. There is some stuff (e.g. synchronized methods pinning the virtual thread) where you have to be careful and find solutions (e.g. using ReentrantLock), but overall it is much easier to use (because transparent) and will be adopted very fast compared to the reactive model with significant impact on performance and resources. I've seen a paper, where the virtual thread model also outperformed the reactive model, but you have to be careful with any performance comparison anyways because one line of code can make a giant difference.
But random educated guess: virtual threads are the deathblow to mass-adoption of reactive in Java. It has it's value in stream processing, but for most use-cases the transparent use of virtual threads will be the go-to solution.
31:45 ... so... where is the pad-left / pad-right which i need surprisingly often?
Could you use this plugin that shows what shortcut you use ?
It's nice to see Java finally getting features Scala had 15 years ago. Welcome to the future.
Uuuuuuhhh Scala hahahaha
still no one wants to use Scala after 15 years later except the minority group keeps whining: I am better than you! I know better than you!. But really no one cares because Scala is not revelant
not sure one but your logo looks like the Durex one :D
Your build is currently configured to use Java 21 and Gradle 8.3. Also used 8.5 nightly build. Can someone help?
The sealed class example was horrible
Too loud keyboard :(
It’s perfect, real asmr for programmers
Ugly code, dont use swtich and if's
nice claim. can the junior show us the alternatives?
@@walterclementsjr.5947 polymorphism will help you