Netty 4.2 的 io_uring 在 Java 8 报 class file version 53.0

Java 8 应用启用 Netty 4.2 的 io_uring transport，加载 IoUringIoHandler 时就报错，尚未建立任何网络连接：

UnsupportedClassVersionError:
io/netty/channel/uring/IoUringIoHandler has been compiled by a more recent version
of the Java Runtime (class file version 53.0),
this version of the Java Runtime only recognizes class file versions up to 52.0

53 对应 Java 9，52 对应 Java 8。这里的限制来自 io_uring 模块：Netty 4.2 的这条 transport 使用 VarHandle，需要 Java 9 及以上。不能把 Netty 其他模块仍支持 Java 8，理解成每一种 transport 都能在 Java 8 上运行。

先看异常中的类属于哪个模块

Netty 4.2.14.Final 的 netty-transport-classes-io_uring 明确按 Java 9 编译。它还专门把用于可用性探测的 IoUring 类按 Java 8 编译；因此，能引用探测类不代表实际 I/O handler 也可以加载。

检查出错进程实际使用的 JVM、依赖树和启动脚本。开发机的 JDK、构建工具链、容器中的运行时可以是三个不同版本。普通终端里执行一次 java -version，只说明当前命令命中的 Java；服务脚本若用了绝对路径，仍要检查那个路径。

Maven 工程可以查看 Netty 的解析结果：

./mvnw dependency:tree -Dincludes=io.netty

Gradle 工程则查看实际运行配置，例如普通 Java 应用的 runtimeClasspath。重点核对有没有混入旧 incubator transport、4.1 和 4.2 的 JAR，或框架间接带来的另一版模块。不同 transport 和 channel 类型也必须匹配，不能只替换一个类名。

两条可行路径，各自保留原有协议设置

能够升级运行时的项目，应选项目与框架共同支持的受维护 JDK，再迁移这条 transport。Java 9 是最低能力边界，不是建议在新部署中安装一个已经过时的 Java 9。升级后仍需确认 Linux 内核、native 库及平台架构满足 io_uring 的条件；通过字节码加载只解决第一层问题。

暂时必须保留 Java 8 时，改用框架支持的 Java 8 transport，例如 NIO；Linux 上的 epoll 也要分别核对当前 Netty 模块和 native 条件。若直接使用 Netty 4.2，可以将 I/O handler 和 channel 类型成对选择，下面仅展示 NIO 服务端的初始化片段：

import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.MultiThreadIoEventLoopGroup;
import io.netty.channel.nio.NioIoHandler;
import io.netty.channel.socket.nio.NioServerSocketChannel;

MultiThreadIoEventLoopGroup group =
        new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
ServerBootstrap bootstrap = new ServerBootstrap()
        .group(group)
        .channel(NioServerSocketChannel.class);

片段没有包含应用已有的 handler、端口绑定和关闭流程。将原来的 TLS、编解码器、socket 选项和生命周期管理保留，再按 NIO 支持范围调整 transport 专用选项；退出时仍应正常关闭 event loop。由框架创建 bootstrap 的项目，应修改框架的 transport 选择入口，不另建一套无人使用的 group。

不要尝试仅把应用的 targetCompatibility 改成 1.8 来修复：它不会重编译已经发布的 Netty JAR。强行把该模块源码目标降到 Java 8，也无法给 Java 8 补上 VarHandle。

验证时先确认不再加载不兼容的 IoUringIoHandler，再检查连接建立、读写、TLS 和优雅关闭。若新错误变成 native 库不可用或 channel 与 event loop 不相容，应沿新的堆栈检查；那已经不是 class file 53 与 52 的问题。保留 transport 选择及依赖差异，回退时成对恢复 handler 和 channel，避免留下混合配置。