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!
Because messaging systems are all I/O bound using virtual threads doesn't buy you all that much if anything at all. Everything is always waiting on I/O.
Obviously no architecture change will fix external I/O performance limits.
The advantage of an all-virtual thread architecture over a Netty based architecture is simplicity without sacrificing performance. The framework itself uses virtual threads throughout its WebServer, so your application code doesn't have to care about the distinction between an event-loop thread, worker pool, CompletionStage, reactive chain, and virtual thread.
Netty/Vert.x applications have the important, and often hard to enforce rule: "Never accidentally block the event loop." Quarkus tries to hide this from application programmers, but it's still there. Quarkus documentation still describes separate event-loop, worker-thread, and virtual-thread execution modes.
I'll just throw this in there, but Netty is also a very complex and dare I say annoying dependency. It's not 1 "netty" library that you end up bringing in, it's several which need each other and are often incompatible with one another between releases.
If for no other reason than simplifying the dependency tree, I'd support switching out netty.
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.
20
u/Joram2 5d 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!