What's Looming in Spring? by VENKAT SUBRAMANIAM & JOSH LONG

[@shapeshifter360]

My two favourite conference speakers at the same time! ❤

[@maneshipocrates]

What a presentation of this difficult topic from the only man who does it better!

[@abobafd]

Great talk!

[@ravinderreddykothabad2299]

Super!!!

[@adhithyansridhar7046]

Again very insightful from Venkat. Josh's body language shows 100% respect he has for a co-speaker. Great to see he collaborated with Venkat Sir.

[@shakilahmed4647]

Two favorite person on the stage wow

[@lhxperimental]

This is the longest time I have seen josh silent

[@MariuszAleksandrowicz]

Nobody presented so far how to create and use in Java 21 with Vitual Threads some concepts welll know in Spring WebFlux like methods zip(), merge(), concat() and many others. How to pass context in downstream comparing to what is use in Spring - Reactor Context. So far it is not a replacement for Reactor.

[@vincentchee4108]

You might get it wrongly. It is meant to completely get rid of the reactive programming paradigm not to be used in tandem with Webflux. You can still use the good old ThreadContext for passing context.

[@Nick-yd3rc]

Yeah, there’s a lot left to be desired, lots of RX stuff glossed over, patterns are yet to be invented, I don’t like the DX. It’s all experimental still. Fibers shouldn’t obviate reactivity, it’s not about lightweight scheduling. It’s about data flows. Many examples spilled over the presentations are disingenuous of reactive patterns. The stack traces are just fine, there’s much less complexity in reactive patterns than when you get to maintain and synchronize hand-rolled event loops. Seeing most dev advocates literally laugh on stage at some contrived RX examples which sometimes still are not as bad as what they seem to propose, and pretending everyone agrees with them, is awkward and feels very alienating, as if they hadn’t written proper software in quite a while and were living in an echo chamber. Reactive Streams implementations can use Virtual Threads, it’s a JDK-managed fork-join pool based event loop with a default implementation of a lightweight user-space thread, which you don’t even have to use. It’s as if the JDK default implementations were generally better than the community libraries. Well, we then wouldn’t have had so many better alternatives.

[@Nick-yd3rc]

Josh: would have been great if you load-tested WebFlux for a proper comparison too.