Spring Tips: Making the Joyful Jump to Java 21
HTML-код
- Опубликовано: 18 сен 2023
- Hi, Spring fans! Java 21 and GraalVM supporting Java 21 are at long last here! It's been a long time in coming, but Java 21 - which comes out later today on the 19th of September, 2023 - brings with it some of the most exciting new features of any Java release. In this video, I ( / @coffeesoftware ) will look at some of the foundational features from Java 17 and see how they culminate in Java 21. I'll look at the biggest features - virtual threads and pattern matching. I'll also look at some of the quality-of-life features that you might not otherwise notice, but that are nice to have. And of course, I'll touch on how virtual threads integrate with Spring Boot 3.2. And, as a bonus, I am joined by two fellow Java Champions (and friends) Enrique Zamudio (x.com/@chochosmx) and Eddú Meléndez (x.com/eddumelendez). There's never been a better time to be a Java developer, and the fun starts right here! #GraalVM #Java #Java21 #SpringBoot #Java
Наука
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.
Excellent content, thanks!
excelent! Thank you! 👍🏻☕️
On assertion the first argument is the expected and the second is the actual value.
Besides that very nice 👍🏻
excellent intro
love u josh ❤
La mejor intro 😂
Josh, get a professional microphone please.
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?
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!
not sure one but your logo looks like the Durex one :D
Could you use this plugin that shows what shortcut you use ?
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
31:45 ... so... where is the pad-left / pad-right which i need surprisingly often?
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.
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
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