Java 生态周报：AOT 与结构化并发 JEP 亮相，CDI 5.0 和 Kotlin ADK 正式发布

2026-09-15 28 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

2026 年 9 月 7 日这一周，Java 生态同时出现了三类值得关注的变化：OpenJDK 继续推动提前编译与结构化并发，新版 Jakarta CDI 和 Kotlin ADK 进入 GA，Gradle 9.8 与 Groovy 6.0 则发布首个候选版本。对工程团队来说，重点不只是“又有哪些版本”，而是判断哪些更新可以进入生产，哪些只适合建立验证分支。

OpenJDK 的两条主线：启动效率与并发可维护性

本周出现的新 JEP 分别指向提前编译（AOT）和结构化并发。这两项工作解决的问题不同，却都与 Java 应用在现代部署环境中的成本有关。

AOT 的价值通常体现在启动时间、预热过程和资源占用上。它对短生命周期任务、按请求扩缩容的服务以及大量小实例尤其重要。不过，团队不应只用“启动快了多少”判断收益，还需要同时记录：

  • 构建产物大小以及构建耗时；
  • 冷启动与热启动延迟；
  • 峰值和稳定阶段的内存占用；
  • 反射、动态代理、运行时生成代码等能力的兼容情况；
  • 与传统 JIT 模式相比的稳定吞吐量。

结构化并发关注的则是任务生命周期。它试图让一组并发子任务拥有清晰的父子关系，使取消、超时、异常传播和资源回收更容易推理。相比把多个异步任务散落在回调或独立线程池中，这种模型更适合“同时请求多个下游，只要一个关键任务失败就取消其余任务”的服务端场景。

由于摘要没有给出 JEP 编号、目标 JDK 版本和 API 阶段，不应假设这些能力已经成为默认稳定接口。准备实验时，要先阅读对应 JEP 的作用域与兼容性说明，并确认是否需要预览开关。可以用下面的通用命令验证一份使用预览 API 的源码；运行前把 JAVA_FEATURE 改成当前测试 JDK 的 feature version：

#!/usr/bin/env bash
set -euo pipefail

JAVA_FEATURE="${JAVA_FEATURE:-26}"
SOURCE_FILE="${1:-Main.java}"
MAIN_CLASS="${2:-Main}"

java --version
javac --enable-preview --release "$JAVA_FEATURE" "$SOURCE_FILE"
java --enable-preview "$MAIN_CLASS"

这段脚本不绑定某个尚未确认的结构化并发 API 形态，适合放进独立实验分支。预览 API 可能在后续版本中变化，因此不要让核心业务接口直接暴露相关类型。

GA、维护版和月度平台版应该区别对待

Jakarta CDI 5.0 与 ADK for Kotlin 1.0 均进入 GA，但“GA”并不等于可以跳过验证。

CDI 5.0 是依赖注入规范层面的升级。采用它之前，应同时核对 Jakarta EE 运行时、注解处理、测试容器以及依赖 CDI 扩展的第三方库。只更新 API 依赖、却继续部署到不支持对应规范版本的容器，往往会把问题推迟到部署或运行阶段。

下面是一个最小 CDI 5.0 编译项目。它只验证标准 API 的源码兼容性，不包含 CDI 容器；生产运行时仍需选择明确支持 CDI 5.0 的 Jakarta EE 平台或独立实现。

mkdir -p cdi5-check/src/main/java/example
cd cdi5-check

cat > pom.xml <<'EOF'
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>cdi5-check</artifactId>
  <version>1.0.0</version>
  <properties>
    <maven.compiler.release>21</maven.compiler.release>
  </properties>
  <dependencies>
    <dependency>
      <groupId>jakarta.enterprise</groupId>
      <artifactId>jakarta.enterprise.cdi-api</artifactId>
      <version>5.0.0</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
</project>
EOF

cat > src/main/java/example/GreetingService.java <<'EOF'
package example;

import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class GreetingService {
    public String greet(String name) {
        return "Hello, " + name;
    }
}
EOF

cat > src/main/java/example/GreetingResource.java <<'EOF'
package example;

import jakarta.inject.Inject;

public class GreetingResource {
    @Inject
    GreetingService service;

    public String greeting(String name) {
        return service.greet(name);
    }
}
EOF

mvn --batch-mode clean package

ADK for Kotlin 1.0 的 GA 则意味着它已达到首个正式发布节点。由于摘要没有提供其具体 API，实际接入时更稳妥的方式是先做一个隔离的代理或工作流样例，固定模型、工具调用、超时和错误处理，再决定是否进入主项目。尤其要测试外部工具失败、重复调用、敏感数据进入提示词以及成本失控等边界。

Open Liberty 发布了 2026 年 9 月版，Micronaut 则提供维护版本。月度平台版通常需要关注功能组合、运行时行为和容器镜像变化；维护版本看似风险较低，也仍然应该执行完整回归，特别是启动配置、序列化、HTTP 客户端和原生镜像相关测试。

TornadoVM、RefactorFirst、Groovy 与 Gradle：升级节奏不能一刀切

TornadoVM 和 RefactorFirst 发布的是小版本。前者涉及异构硬件加速场景，升级时应保留性能基线，而不是只检查功能测试是否通过；后者属于架构分析与重构辅助工具，更适合先在 CI 中以非阻断任务运行，观察报告是否稳定，再考虑把阈值变成质量门禁。

Groovy 6.0 和 Gradle 9.8 当前是首个发布候选版本。RC 的意义是让用户验证接近最终版的构建，而不是要求生产项目立即升级。Gradle 升级尤其要检查插件兼容性、弃用警告、构建缓存、配置缓存以及自定义任务。

可以在临时分支中测试 Gradle 9.8 RC1：

git switch -c test/gradle-9.8-rc1

./gradlew wrapper --gradle-version 9.8-rc-1
./gradlew clean test --warning-mode all
./gradlew build --scan

git status --short
git diff -- gradle/wrapper gradlew gradlew.bat

如果项目不能上传构建扫描数据，应删除 --scan。验证完成后，不要只看测试是否为绿色，还要搜索弃用信息并比较构建时间：

./gradlew clean build --warning-mode all 2>&1 | tee gradle-9.8-rc.log
grep -iE 'deprecated|deprecation|incompatible' gradle-9.8-rc.log || true

Groovy 6.0 RC 同样应该先覆盖动态调用、AST 转换、编译插件以及 Gradle 脚本。使用 Groovy DSL 的 Gradle 项目，还需要把 Groovy 与 Gradle 的变化放在同一个兼容性矩阵中，而不是分别验证后直接组合。

本周适合采取的升级策略

可以按发布成熟度建立三条通道：

  1. 生产候选通道：评估 CDI 5.0、ADK for Kotlin 1.0，以及与当前平台匹配的 Open Liberty 月度版和 Micronaut 维护版。
  2. 工具验证通道：试用 TornadoVM、RefactorFirst 的小版本，保留升级前后的性能或架构报告作为对照。
  3. 实验通道：隔离测试新 JEP、Groovy 6.0 RC 和 Gradle 9.8 RC，不让预览 API 或候选版构建工具直接控制生产发布。

进入升级窗口前，至少确认运行时与规范版本匹配、构建插件没有阻断性问题、回滚产物可用，并为 AOT 和并发模型保留可重复的性能基线。这样，这份周报才会从版本清单变成可执行的工程计划。

# AI # InfoQ # Java # 全栈 # 后端

相关推荐