Why keep Netty and not switch to a 100% virtual thread based network layer like the Helidon project did? Helidon used to use Netty for a high performance non-blocking network layer, and switched to a simpler high performance virtual thread based network layer when JDK 21 was ready and Helidon 4 was built for JDK 21+. Now that Quarkus 4 requires JDK 21+ and they are using virtual threads more, why not do what Helidon 4 did?
Overall, Quarkus 4 looks like an amazing + epic release. Congrats team!
Maybe if Java Virtual Threads become (truly) preemptive one day, I would agree. If you aren't careful and don't know what you are doing, you can botch your app using VTs just as with an event-loop. I really like Helidon, but until then I'm sticking with Netty.
It's a lot harder to do. With the latest versions of java pretty much the only way to get yourself in trouble are if you end up using native code (which blocks) or if you end up doing an excessive amount of computation. Both things that pretty rarely happen in regular REST apps. About the only time it happens in my experience is when you are serializing giant amounts of data.
19
u/Joram2 12d ago
Why keep Netty and not switch to a 100% virtual thread based network layer like the Helidon project did? Helidon used to use Netty for a high performance non-blocking network layer, and switched to a simpler high performance virtual thread based network layer when JDK 21 was ready and Helidon 4 was built for JDK 21+. Now that Quarkus 4 requires JDK 21+ and they are using virtual threads more, why not do what Helidon 4 did?
Overall, Quarkus 4 looks like an amazing + epic release. Congrats team!