https://docs.oracle.com/en/java/javase/17/docs/api/jdk.https...
It's built on top of Netty but has some additional niceties that make it more practical to use. It's also one of the fastest things out there: https://www.techempower.com/benchmarks/#section=data-r18&hw=...
I'm not on the engineering team so can't speak to the cost/benefit, but it seems to have been a pretty successful transition.
Netty copies the response body when sending to each client, so it's not as lightweight as I've found. For streaming large response bodies, it does not work well. I haven't found a good Java alternative yet (probably will switch to C++ and uWS...)
Quote: "But how does Netty do things so fast ? One of the reasons is that it is using native memory pool to store network buffers. If you did some file reading or network action with Vert.x you probably used io.vertx.core.buffer.Buffer class. This class is actually a wrapper around Netty io.netty.buffer.ByteBuf class. Why am I telling you all this ? Let assume that you have a service where clients are downloading 20Mbyte files. Netty will have to allocate at least 20Mbyte for every connected client."
Although this may be an issue with how Vert.x is using Netty. I have to dig into it more.
I'm not very familiar with vert.x(not a netty expert either), but I think the author of that article is ascribing blame to the wrong place.
[0]: https://github.com/juggernaut/netty-websocket-broadcast-exam...
This is similar to .NET Standard 2.1 Span<T>?
A bit outdated and not actively maintained, but it's truly small.
If you like async stuff, take a loot at Helidon.
It can use netty, undertow, and others under the hood