Java 周报:TornadoVM 5.0 正式发布,Jakarta EE 11 迎来 Vidocq

2026-07-13 44 预计阅读时间: 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.

预计阅读时间:9 分钟

2026 年 7 月 6 日这一周的 Java 动态横跨多个层次:TornadoVM 5.0 进入 GA,JHipster、Keycloak 与 Google ADK 发布小版本更新,GraalVM Native Build Tools 和 Micronaut 推出维护版本,OmniFish 带来自己的 Payara 构建,同时 Vidocq 作为 Jakarta EE 11 Core Profile 与 MicroProfile 7.1 的新实现亮相。对开发团队来说,这不只是一串版本号,而是运行时、云原生框架、身份系统和 AI Agent 工具链同时发生变化。

TornadoVM 5.0:GA 意味着可以开始正式评估

TornadoVM 的目标是让 Java 程序利用 GPU 等异构硬件执行计算密集型任务。5.0 达到 GA,是本周最明确的里程碑,但 GA 并不等于可以直接替换生产环境中的普通 JVM。

评估时应先寻找适合加速的工作负载,例如大规模数组运算、图像处理、数值模拟或机器学习预处理。数据库访问、网络等待和大量小对象分配通常不会因为切换异构计算运行时而自然提速。

团队应记录三类结果:

  • 端到端延迟,而不只是计算内核耗时;
  • 首次执行、预热后执行和持续吞吐量之间的差异;
  • CPU、GPU、驱动程序和操作系统组合对结果的影响。

如果测试环境依赖特定加速器,还需要把驱动版本和设备信息纳入构建记录。否则,同一份 Java 代码可能在不同开发机上产生无法比较的基准结果。

小版本与维护版本:风险不大,但不能跳过验证

JHipster、Keycloak 和 Google ADK 本周发布的是小版本更新;GraalVM Native Build Tools 与 Micronaut 则以维护更新为主。这类版本通常比大版本容易采用,但它们触及的环节并不轻:JHipster 管理项目脚手架,Keycloak 位于认证链路,Native Build Tools 影响原生镜像构建,Micronaut 则可能贯穿依赖注入、配置与 HTTP 服务启动过程。

Google ADK 的更新还涉及正在快速演进的 Agent 开发领域。Agent 应用不仅要验证代码能否启动,还要固定模型、提示词、工具输入和最大执行轮数,再比较升级前后的工具调用序列。仅检查最终文本,很容易漏掉成本上升、重复调用或错误重试等回归。

更稳妥的升级顺序是:先更新构建与开发工具,再处理应用框架,最后升级身份系统等共享基础设施。Keycloak 之类的组件还应覆盖登录、令牌刷新、登出、角色映射和服务账号,而不是只做一次首页登录。

Jakarta EE 实现正在增加

OmniFish Build of Payara 和新出现的 Vidocq,说明 Jakarta EE 生态仍在扩展实现选择。摘要明确指出,Vidocq 面向 Jakarta EE 11 Core Profile 和 MicroProfile 7.1。这里的关键词是“Core Profile”:它不应被直接理解为完整 Jakarta EE 平台的等价替代品。

评估 Vidocq 时,应先列出应用实际使用的 API,再与目标 Profile 对照。一个只依赖 Jakarta REST、依赖注入和 JSON 处理的微服务,与依赖完整持久化、消息系统和企业级事务的应用,迁移难度完全不同。

OmniFish Build of Payara 也应该按独立发行物管理。即使名称中包含 Payara,团队仍需单独确认其构建来源、补丁策略、支持范围、镜像标签和升级节奏,避免把不同构建当成可无条件互换的二进制文件。

可以这样实践:为 Java 依赖升级建立可重复门禁

来源摘要没有给出各个小版本的精确版本号,因此下面不假设具体坐标,而是提供一套可以直接放进 Maven 项目的升级检查脚本。运行前需要安装 JDK 21 和 Maven;如果项目使用 Maven Wrapper,可把 mvn 改成 ./mvnw

创建 verify-upgrade.sh

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

java -version
mvn -version

mvn --batch-mode --no-transfer-progress \
  clean verify

mvn --batch-mode --no-transfer-progress \
  org.owasp:dependency-check-maven:check

mvn --batch-mode --no-transfer-progress \
  versions:display-dependency-updates \
  versions:display-plugin-updates

执行命令:

chmod +x verify-upgrade.sh
./verify-upgrade.sh

这段脚本依次确认工具链、运行完整测试、执行依赖漏洞检查,并列出依赖与 Maven 插件的可用更新。首次运行 OWASP Dependency-Check 时需要下载漏洞数据,耗时会明显更长;企业网络通常还需要配置代理或内部镜像。

对于 Keycloak 或其他外部服务,建议再补一组独立的集成测试。下面是一个可改造的令牌端点探测脚本,其中 URL、realm、客户端和测试账号都通过环境变量传入,避免把凭据写进仓库:

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

: "${KEYCLOAK_URL:?Set KEYCLOAK_URL}"
: "${KEYCLOAK_REALM:?Set KEYCLOAK_REALM}"
: "${KEYCLOAK_CLIENT_ID:?Set KEYCLOAK_CLIENT_ID}"
: "${KEYCLOAK_USERNAME:?Set KEYCLOAK_USERNAME}"
: "${KEYCLOAK_PASSWORD:?Set KEYCLOAK_PASSWORD}"

curl --fail-with-body --silent --show-error \
  -X POST \
  "${KEYCLOAK_URL}/realms/${KEYCLOAK_REALM}/protocol/openid-connect/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "client_id=${KEYCLOAK_CLIENT_ID}" \
  --data-urlencode "username=${KEYCLOAK_USERNAME}" \
  --data-urlencode "password=${KEYCLOAK_PASSWORD}" \
  --data-urlencode "grant_type=password"

密码授权是否可用取决于客户端配置,也不适合所有生产场景;这里把它作为受控测试环境中的探测示例。生产系统应按照实际采用的授权码、客户端凭据或设备授权流程编写测试。

采用建议

本周最值得立项验证的是 TornadoVM 5.0 和 Vidocq:前者可能改变计算密集型 Java 任务的执行方式,后者为 Jakarta EE 11 Core Profile 与 MicroProfile 7.1 增加了实现选择。两者都应从小型、可测量的服务或计算任务开始,而不是直接迁移核心系统。

其余小版本和维护版本可以进入常规升级队列,但至少要完成以下检查:锁定 JDK 与构建工具版本、阅读对应发行说明、运行单元与集成测试、扫描依赖漏洞、验证原生镜像、回归身份流程,并准备可执行的回滚方案。Java 生态的版本更新越来越频繁,真正能降低风险的不是延迟升级,而是把升级变成一条可重复运行的工程流程。


相关推荐