After a lot of work and many contributions from our OSS community we are thrilled to finally announce the release of netty 4.2.0.Final! Everyone using netty 4.1.x should be able to upgrade to 4.2.0.Final without any API breakage. The only new requirement is JDK8 or later (and JDK9+ for io_uring) and a more recent GLIBC version when using our native transports.

With the release of netty 4.2.0.Final we will also start to only merge bug-fixes into 4.1, new features will only be merged to 4.2 and main branches. While 4.1.x releases will only receive bug-fixes we will still support it 4.1.x for the time beeing, so projects can take their time to upgrade to 4.2.0.Final. That said as the upgrade should be painless we advice people to do so rather sooner than later.

Please refer to our Migration Guide for all the details related to upgrades. This document also contains sections highling some best practices related to new features introduced in 4.2.

Netty 4.2.0.Final will come with some exciting new features that you can learn more about detail in our Migration Guide.

New Features

This section highlights some of the most exciting features for the end-user.

AdaptiveByteBufAllocator

In Netty 4.1.x the adaptive memory allocator was experimental. We have now made it the new default instead of the pooled allocator.

We believe that most workloads will observe reduced memory usage, with performance that is on par or slightly better than the pooled allocator. The adaptive allocator automatically tunes itself to perform well for the observed workload. It was also designed from the start to work well with virtual threads.

MultiThreadIoEventLoopGroup

In previous versions of netty the EventLoopGroup implementation was tightly coupled to the respective Channel implementation. This made it very hard to extend existing EventLoopGroups to add functionality like instrumentation (especially because you might want to use different transports based on the platform you are running on).

This has changed in 4.2.0, here you will use one EventLoopGroup implementation (MultiThreadIoEventLoopGroup) for all transports. This allows for easier customization of it (think of it like ThreadPoolExecutor that can be extended and customized). To make this possible we extracted the whole IO handling / multiplexing to another class that is injected into the MultiThreadIoEventLoopGroup.

For example:

new EpollEventLoopGroup();

becomes

new MultiThreadIoEventLoopGroup(EpollIoHandler.newFactory();

Other transports follow the same pattern.

MultiThreadIoEventLoopGroup and SingleThreadIoEventLoop provide various methods that can be overridden by the user and so provide the ability to:

• get a count of registered Channels / IoHandles
• understand how long the io processing vs task processing took
• how many Channels / IoHandles were processed per loop run
• customize / decorate Promise, Future.

Furthermore, it is now possible to register other things than Channels, which provides a lot of possibilites to re-use netty components and also add support for other IoHandle implementations which does not exists as of today. For example, this could be used to implement file IO with io_uring. For a proof of concept see #14432.

io_uring support

In Netty 4.2.0.Final we have graduated the io_uring transport from incubator, to a fully supported first-class transport module.

As part of this work, we have made numerous refactorings to the Netty transport internals that render the incubator version entirely incompatible. The good news is that netty-transport-native-io_uring is a much superior implementation thanks to these refactorings.

Integrators are encouraged to stop using the incubator module, and instead move to Netty 4.2.0.Final for its superior io_uring integration. Doing so will unfortunately require code changes. Please refer to the Migration Guide.

With the integration of io_uring into 4.2.0.Final we also will not continue to ship io_uring support for 4.1 (as part of the incubator project). Special thanks to @axboe for all the feedback and help and quickly reacting to feedback that caused changes to io_uring itself.

ManualIoEventLoop

In the past people often asked if it would be possible to "drive" the EventLoop manual, which basically means to own the Thread that drives the EventLoop itself and decide by themselves when io / tasks are processed. This was not possible in netty 4.1 due of the tight coupling of EventLoopGroups and Channels. As this is not the case anymore with 4.2.0 we did revisit this feature request and were able to provide an implementation which does exactly what people have asked for.

An example of its usage would be:

    Thread currentThread = Thread.currentThread();
    ManualIoEventLoop eventLoop = new ManualIoEventLoop(currentThread, NioIoHandler.newFactory());
    ServerBootstrap bootstrap = new ServerBootstrap();
    Channel channel = bootstrap.channel(NioServerSocketChannel.class)
            .handler(serverHandler).bind(0);
    while (!eventLoop.isTerminated()) {
        doSomeworkOtherWork();
        eventLoop.runNow();
    }

ManualIoEventLoop exposed various methods which allows to either run everything that is ready yet, or block until there is something ready. Please refer to the javadocs for more details. That said this is an advanced feature and should only be used if there is a good use-case for it as care needs to be taked to process IO / tasks in a timely manner.

General changes

The most important changes in this release (compared to the previous release candidate) are:

• Add suppressed exception to original cause when calling Future.sync* (#14898)
• IoUring: Guard against possible crash when resources are accessed after closure (#14904)
• IoUring: Correctly calculate ioPrio when using multishot accept (#14907)
• IoUring: Correctly handle late removal of registration for multishot completions (#14913)
• IoUring: Use correct native jni types in function definition (#14914)
• IoUring: Expand buffer ring on the fly (#14916)
• IoUring: Fix AssertionError caused by racing cancellation and completion (#14921)
• Fix channel de-registering executor cache clear bug (#14924)
• Fix allocateUninitializedArray invocation via MH (#14931)
• IoUring: Ensure close completes before closing the eventloop group (#14933)
• IoUring: Ensure we guard against segfaults in all cases (#14938)
• Adaptive: Correctly enforce leak detection when using AdaptiveByteBufAllocator (#14946)
• IoUring: Allow to use io_uring without sun.misc.Unsafe (#14962)
• IoUring: Correctly memset struct io_uring (#14968)
• Build Netty 4.2 on CentOS 7 (#14973)
• Disable sun.misc.Unsafe by default on Java 24+ (#14975)
• Allow delayed set of owningThread in ManualIoEventLoop (#14976)
• Fix support for DH_anon and ECDH_anon authentication methods (#14977)
• HTTP2: Allow to manually manage window update frames when using Http2StreamChannel (#14980)
• Fix timeout when auto read is disabled late in io_uring (#14989)

For all the changes please vision our issue-tracker.

Thank You

Every idea and bug-report counts, and so we thought it is worth mentioning those who helped in this area.

Please report an unintended omission.

• @axboe
• @bryce-anderson
• @chrisvest
• @dreamlike-ocean
• @franz1981
• @He-Pin
• @mkurz
• @normanmaurer
• @Spasi
• @vietj
• @yawkat

Beside this we also would like to thank everyone who took the time to test all the alpha, beta and release-canidates of netty 4.2.0. Without the feedback it would have been impossible to complete this release.