JDK 28 锁定结构化并发等三项 JEP，Grails 8 强制最低 JDK 21 与 Gradle 9.7

一句话结论

Java 生态本周发布多项关键更新，JDK 28 目标功能确定，Grails 8.0.0 发布并提升最低版本要求，显著影响开发环境与框架选型。

关键要点

• JDK 28 将包含 JEP 543（结构化并发）、JEP 545（ZGC 启动优化）及 JEP 546（ZGC 堆自适应），评审已于 2026 年 10 月中旬结束。
• Apache Grails 8.0.0 发布，最低支持版本变更为 JDK 21 和 Gradle 9.7，所有控制器改为通过 REST 资源机制解析。
• LangChain4j 1.22.0 正式版新增 BedrockBatchChatModel，并支持 OpenAI Decisions API 相关模型类。
• Micronaut Framework 5.2.2 升级 Netty 至 4.2.19.Final，修复包括 HTTP 请求走私在内的 16 个 CVE 漏洞。
• Spock 2.5.0 发布，正式支持 Groovy 6 和 Spring Framework 7，并改进交互测试错误报告机制。

背景与事实

在 OpenJDK 进展方面，三项重大 JEP 状态更新确立了 JDK 28 的核心功能方向。JEP 543（结构化并发）在经过从 JDK 21 到 JDK 27 的七轮预览以及两轮孵化后，没有进行任何修改，最终确定将相关任务组视为单一工作单元，以简化错误处理和取消操作。JEP 545 和 JEP 546 分别针对 ZGC 垃圾收集器进行了增强，前者旨在通过更高效地获取和准备物理内存来加快启动和预热过程，后者则允许堆大小根据可用资源和邻近应用需求进行自适应调整。这三项 JEP 的评审分别于 2026 年 10 月 13 日和 10 月 14 日结束。与此同时，JDK 28 的早期访问构建 Build 19 已发布，作为 Build 18 的升级版本修复了多处问题。惰性常量功能的第四个预览版（JEP 547）也进入候选状态，该功能历经三轮预览，定义为最多初始化一次的不可变值容器，名称从“稳定值”变更以更准确体现其意图。

在框架与库层面，Apache Grails 发布了 8.0.0 版本，引入了多项关键变更。新标准要求 JDK 21 和 Gradle 9.7 作为最低支持版本，这意味着使用旧版本环境的开发者必须进行升级。架构上，Grails 控制器现在均作为 REST 资源，通过请求而非映射来解析，且 Grails Promises 机制改为基于 Spring Boot Task Executor 运行。LangChain4j 团队发布了 1.22.0 正式版，该版本新增了 BedrockBatchChatModel 类以实现 Bedrock 批量推理 API，并引入了 OpenAiDecisionModel 和 OpenAiOfficialDecisionModel 以支持 OpenAI Decisions API。Micronaut Framework 5.2.2 基于 Micronaut Core 5.2.15 发布，重点在于安全更新，通过升级 Netty 至 4.2.19.Final 修复了 16 个 CVE，其中包括 HTTP 请求/响应走私及 HTTP 编解码器中的无界资源消耗问题。Spock 2.5.0 的发布带来了对新版本语言支持，正式兼容 Groovy 6 和 Spring Framework 7，同时改进了 TooManyInvocationsError 类，使其能报告未满足预期的交互，并支持在 where: 代码块中声明 final 局部变量。

此外，中间件与运行时也发布了重要更新。Open Liberty 26.0.0.10 GA 版本发布，增加了对 JDK 27 的支持，并修复了七个 CVE。值得注意的是，G1 垃圾回收器已成为所有环境的默认设置，这在受限环境中可能改变原有的垃圾回收行为。Infinispan 16.3.0（代号 Tripel Karmeliet）发布了多项优化，包括在合并分区时采用基于哈希的冲突检测机制，实现属性存储的持久化，以及优化日志记录以减少噪音。TornadoVM 发布了 7.2.0 和 7.1.0 版本，新增 mmaLoadA() 和 mmaLoadB() 方法以返回 HalfFloat 类片段，并更新了 CUDA 相关类以准确报告驱动程序调度时间。GlassFish 8.0.5 则更新了 ZipPayloadImpl 类以符合 ZIP64 规范，并优化了部署时间。

影响分析

对于中文开发者与从业者而言，Grails 8.0.0 的发布具有直接的工程约束意义。由于最低支持版本提升至 JDK 21 和 Gradle 9.7，依赖旧版 JDK 或 Gradle 的项目若计划迁移至 Grails 8，必须进行基础环境升级，否则无法构建。这要求团队在升级计划中预留时间处理潜在的兼容性问题。同时，控制器解析机制从映射改为基于请求的 REST 资源解析，可能改变开发者的编码习惯和路由配置逻辑，需要重新审视现有的控制器实现。

在安全性方面，Micronaut 和 Open Liberty 发布的 CVE 修复版本提示运维与开发团队应尽快升级相关组件。特别是 Netty 升级修复的 HTTP 请求走私漏洞，对于处理高流量请求的服务至关重要。Open Liberty 默认垃圾回收器变更至 G1 的分析判断是，在资源受限的生产环境中，团队需重新评估内存配置，避免默认的 G1 行为导致性能波动或资源不足。对于 AI 应用开发者，LangChain4j 1.22.0 新增的 Bedrock 批量推理和 OpenAI Decisions 支持，降低了集成这些最新 API 的技术门槛，但需关注 1.22.0 作为正式版与后续 Beta 版本的稳定性差异。

适用边界

本文结论主要适用于正在规划使用 Grails 8.0.0 或考虑升级到 JDK 28 的开发团队，以及使用 Micronaut、LangChain4j、Spock 等库的项目。对于仍维护 Grails 7 或更早版本且无升级计划的项目，Grails 8 的最低版本要求不直接构成阻碍，但需注意长期支持的策略变化。Open Liberty 的 G1 默认行为变更主要影响运行在受限环境（如容器内存严格限制）下的场景，在资源充足的环境中影响可能不显著。JDK 28 的早期访问构建（Build 19）仅适用于开发测试环境，严禁直接用于生产部署。

孤本观察

Grails 8.0.0 强制将最低 JDK 版本提升至 21，反映了 Java 生态向现代 LTS 版本快速收敛的趋势，这可能加速旧版本框架的淘汰。TornadoVM 增加对 HalfFloat 片段的支持及 LangChain4j 增加批量推理接口，表明底层基础设施正在针对 AI 工作负载进行专用优化，开发者需关注这些专用接口对性能的影响。

来源：InfoQ 中文 AI