7 月 27 日这一周的 Java 新闻横跨运行时、构建工具、云原生框架和 AI：多项 OpenJDK JEP 已经面向 JDK 28 推进，Maven 4.0 发布第六个候选版本，Jakarta Agentic AI 1.0 迎来首个里程碑版本，GPULlama3.java 1.0 则正式 GA。与此同时，Micronaut、Quarkus、JobRunr 和 JDKUpdater 都发布了增量更新。
这些版本的成熟度并不相同。JEP、里程碑版本、RC 和 GA 分别对应不同的采用策略，团队不应把它们放进同一条升级流水线统一处理。
JDK 28 的信号来自 JEP，而不是最终功能清单
本周有一批 OpenJDK JEP 被标记为已面向或提议面向 JDK 28。这里需要注意措辞：JEP 进入目标版本，代表相关工作向 JDK 28 靠近，但不能简单等同于最终发布版已经锁定全部行为。
对应用团队来说，现在更适合做兼容性侦察，而不是直接制定生产环境升级日期。可以重点检查三个方面：
- 构建插件、注解处理器和字节码工具是否依赖内部 JDK API。
- 测试环境是否能够覆盖下一代 JDK 的早期构建版本。
- 容器基础镜像、监控 Agent 和诊断工具是否跟得上类文件格式及运行时变化。
如果项目维护多条 JDK 基线，可以这样实践：用 Maven Toolchains 明确测试所使用的 JDK，避免开发机上的默认 JAVA_HOME 悄悄改变构建结果。下面的配置不依赖 JDK 28 的具体 JEP，可直接改造成兼容性测试入口。
先在 ~/.m2/toolchains.xml 中把路径替换为本机实际安装位置：
<?xml version="1.0" encoding="UTF-8"?>
<toolchains>
<toolchain>
<type>jdk</type>
<provides>
<version>21</version>
<vendor>any</vendor>
</provides>
<configuration>
<jdkHome>/opt/jdks/jdk-21</jdkHome>
</configuration>
</toolchain>
</toolchains>
然后在现有 Maven 项目中运行：
./mvnw --version
./mvnw -ntp clean verify
接入 JDK 28 早期构建后，可以新增一条允许失败的 CI 任务，替换 toolchain 版本和路径，再执行同一组测试。这样能够提前暴露编译器、插件和运行时兼容问题，又不会阻塞主分支交付。
Maven 4 RC6：适合验证构建，不等于全面切换
Maven 4.0 已来到第六个候选版本。RC 阶段通常意味着主要能力正在收敛，但对企业构建而言，真正的风险往往不在 Maven 核心，而在插件、父 POM、私有仓库和 CI 镜像组成的长依赖链。
试用 Maven 4 时，应保留 Maven Wrapper，并在隔离分支或独立流水线上比较 Maven 3 与 Maven 4 的结果。下面这段脚本可以放到项目根目录执行；它会记录环境信息并完成一次干净构建：
#!/usr/bin/env bash
set -euo pipefail
java -version
./mvnw --version
./mvnw -ntp -DskipTests dependency:tree > dependency-tree.txt
./mvnw -ntp clean verify
验证时不要只看“构建成功”。还应比较生成物校验值、依赖树、测试数量以及部署到私有仓库后的坐标和元数据。若项目依赖自定义 Maven 扩展，更应单独测试，因为扩展通常比普通插件更贴近 Maven 内部机制。
Java AI 工具开始分成两条路线
GPULlama3.java 1.0 的 GA 发布，说明 Java 生态正在探索更贴近 GPU 和本地模型执行的路线。另一方面，Jakarta Agentic AI 1.0 的首个里程碑版本面向 Agentic AI，体现的是规范和应用编程模型方向。
两者解决的问题并不相同：本地模型执行关注模型加载、硬件利用率、内存和推理延迟；Agent 框架则更关心工具调用、上下文管理、工作流编排和可观测性。团队在评估时应先确定自己缺少的是推理引擎，还是稳定的 Agent 应用边界。
由于摘要没有给出 Jakarta Agentic AI M1 的具体 API，下面仅给出一个明确标注为假设的伪项目结构，用来说明早期评估时应该隔离哪些接口，而不是声称这是该里程碑版本的正式 API：
agent-evaluation/
├── pom.xml
└── src/main/java/example/
├── SupportAgent.java
├── ModelGateway.java
└── TicketTool.java
可以先用自己的接口包住模型和工具调用：
package example;
public final class SupportAgent {
private final ModelGateway model;
private final TicketTool tickets;
public SupportAgent(ModelGateway model, TicketTool tickets) {
this.model = model;
this.tickets = tickets;
}
public String handle(String request) {
String ticketContext = tickets.findRelevantTickets(request);
return model.generate(request, ticketContext);
}
public interface ModelGateway {
String generate(String request, String context);
}
public interface TicketTool {
String findRelevantTickets(String request);
}
}
这层隔离能降低里程碑 API 继续变化时的迁移成本，也便于在本地 GPU 推理、远程模型服务和测试替身之间切换。
框架和运维工具更新应按影响面分批处理
Micronaut、Quarkus 和 JobRunr 本周发布的是点版本，JDKUpdater 则属于维护版本。点版本通常比大版本更容易采用，但依然可能影响原生镜像构建、依赖注入、序列化、数据库迁移或后台任务执行。
升级 Micronaut 或 Quarkus 时，应至少验证 JVM 与原生构建两条路径；升级 JobRunr 时，要重点检查任务序列化、重试语义、数据库表结构和多节点调度；更新 JDKUpdater 这类运维工具时，则要验证下载源、代理、校验和、权限及回滚路径。
一个可执行的升级顺序是：
- 先处理点版本和维护版本，每个组件独立提交，保留清晰回滚点。
- 在旁路 CI 中验证 Maven 4 RC6，不立即替换所有开发机与生产流水线。
- 为 JDK 28 建立前瞻兼容任务，暂不把早期版本作为发布基线。
- 将 Jakarta Agentic AI M1 放进实验仓库，通过适配层控制 API 变化。
- 只有在确实需要本地模型推理时，才评估 GPULlama3.java 1.0 的 GPU、驱动、显存和部署约束。
本周更新的共同主题不是“立刻升级”，而是 Java 技术栈正在同时向下一代 JDK、Maven 4 和 AI 工作负载推进。成熟团队应根据版本阶段划分生产升级、兼容性验证和技术实验三条通道，让新能力进入视野，但不让候选版或里程碑 API 无意间成为生产系统的硬依赖。