Virtual threads is a game changer for reactive. The pitfalls of reactive in combination with legacy database drivers is crazy and cannot be argued for now that you can do the same - honestly, even a lot more performant because resource access is actually handled non-blocking - by 'just a few lines of code in a configuration file'. All of a sudden, I can again hire every Java engineer and nobody needs to build complex reactive queries combining multiple data streams that in the end - guess what - are blocking anyway because R2DBC doesn't support relations for relational databases so we we use blocking calls for any database access and lose all the theoretical gains. Everything else is really nice but this is the best feature for me personally.
@@europeantechie " are blocking anyway because R2DBC doesn't support relations for relational databases" You're conflating the threading I/O model with ORM behavior. You then conclude something that is provably false. R2DBC 'understands relations' just as well as JDBC does. If you need joins and projections... write them. If you want a reactive alternative to JPA, Hibernate has a reactive offering. If you insist on misusing R2DBC and zip() together a bunch of async results sets, there is STILL no blocking. Thats... the entire point. Its still a dumb idea but at least you're not wasting threads to fail.
@@57skies What part of my small comment suggests something like that??. It doesn't matter if webflux use netty or virtual threads. The simple idea of maintaining another ecosystem in parallel for very few benefits and serious problems is just insane. Only time will tell. Good luck
@@loooke7197 In my opinion, if the code is difficult to debug, with useless stack trace, poor readability, poor interaction with platform tools, and also aims to fork every library in the ecosystem that touches IO, then yes, it has serious problems and this is not only specific to java, but at least we have a friendly alternative (virtual threads) in front of us.
@@ocleidyreve6361 Thanks. Yeah, i hated working with Weflux also. I recently created an API that used WebClient library. So I had to make the whole API reactive since webclient is reactive. It was such a headache.
so is there a reason they are moving at the is speed? why didn't they move as fast before? also does this mean those certification exams and the people who make them are FAQ'd, since it takes way longer to make those?
It's always a great feeling to get a Spring lecture from Brad Pitt
Nice advice - keep your JDK/EE/Spring Framework keep upto date. World is moving faster.
I’m so glad to see his face. His name is ALL over Spring code.
Virtual threads is a game changer for reactive. The pitfalls of reactive in combination with legacy database drivers is crazy and cannot be argued for now that you can do the same - honestly, even a lot more performant because resource access is actually handled non-blocking - by 'just a few lines of code in a configuration file'. All of a sudden, I can again hire every Java engineer and nobody needs to build complex reactive queries combining multiple data streams that in the end - guess what - are blocking anyway because R2DBC doesn't support relations for relational databases so we we use blocking calls for any database access and lose all the theoretical gains.
Everything else is really nice but this is the best feature for me personally.
You're conflating a bunch of ideas here; you have no idea why you're upset.
@@adambickford8720 I thought I was very precise, feel free to point out inconsitencies - but be more precise when you do so.
@@europeantechie " are blocking anyway because R2DBC doesn't support relations for relational databases"
You're conflating the threading I/O model with ORM behavior. You then conclude something that is provably false.
R2DBC 'understands relations' just as well as JDBC does. If you need joins and projections... write them. If you want a reactive alternative to JPA, Hibernate has a reactive offering.
If you insist on misusing R2DBC and zip() together a bunch of async results sets, there is STILL no blocking. Thats... the entire point. Its still a dumb idea but at least you're not wasting threads to fail.
@@adambickford8720 that is actually a good starting point to dig deeper, thanks for taking the time
Thanks for the good information
AOT (Ahead-Of-Time) and Virtual Threads are interesting!
Brad Pitt giving walk through , I want Tom Cruise also :)
Thanks!
💌 spring , but I think Amazon Lamda SnapStart is based on project Crac
and here i am struggling with spring 5
yessssss🥲
WoW is 18 years old too 😁
is there a place from where I can download these slides??
So, they will continue wasting time with webflux after virtual thread GA....Good luck
so you think that webflux is going to be based in something different when loom is production ready? You seems to miss-understand things
@@57skies What part of my small comment suggests something like that??.
It doesn't matter if webflux use netty or virtual threads.
The simple idea of maintaining another ecosystem in parallel for very few benefits and serious problems is just insane.
Only time will tell. Good luck
@@ocleidyreve6361 just for my understanding, are u saying webflux has only few benefits and serious problems ? (I'm new to spring boot)
@@loooke7197 In my opinion, if the code is difficult to debug, with useless stack trace, poor readability, poor interaction with platform tools, and also aims to fork every library in the ecosystem that touches IO, then yes, it has serious problems and this is not only specific to java, but at least we have a friendly alternative (virtual threads) in front of us.
@@ocleidyreve6361 Thanks. Yeah, i hated working with Weflux also. I recently created an API that used WebClient library. So I had to make the whole API reactive since webclient is reactive. It was such a headache.
interesting. thanks
Tel Aviv, Palestine is absolutely stunning ....
butthurt spotted
Video quality reduced to 360p
First
second
Third
terrible framework
wo wo wo, what happened?
Terrible dev spottted
@@sommyaruproy8405 lol i'm not a nigga i use Rust, not Java
so is there a reason they are moving at the is speed? why didn't they move as fast before? also does this mean those certification exams and the people who make them are FAQ'd, since it takes way longer to make those?
Make Spring boot more minimalist. it is too verbose.
Great explanation of virtual threads