Gradle 9.8.0（2026-09-24 GA）把两件开发者天天磕到的事正式落地了：Daemon / Toolchain 对 Java 27 的支持，以及 org.gradle.mirror.maven.settings 复用 Maven 的 mirror 配置。另外，部分 Windows（尤其虚拟化环境）上因慢系统时钟拖慢构建的问题，也在这版做了自动改时间源的优化。

本文按官方 9.8.0 Release Notes 整理「怎么改、注意什么」。文内配置与命令未在本地机器完整跑通，落地前请以官方文档与你仓库的 ./gradlew 实测为准。InfoQ 周报里也提到了同一版本的 Java 27 / mirror / Windows 性能点，可作交叉阅读：Java News Roundup · Sep 21, 2026。

先升到 9.8.0

在项目根目录更新 Wrapper（官方推荐写法）：

./gradlew :wrapper --gradle-version=9.8.0 && ./gradlew :wrapper

然后确认：

./gradlew --version

升级到 9.x 线时，务必对照 Gradle 9.x Upgrade Guide 看弃用与破坏性变更；Java / Groovy / Kotlin / Android 兼容矩阵见官方 Compatibility。

Java 27：Daemon + Toolchain

9.8.0 起，你可以：

  1. 用 Java 27 跑 Gradle Daemon（构建进程本身）
  2. 用 Toolchain 指定编译 / 测试用的 JDK 27（与 Daemon JDK 可以分开）

Kotlin DSL 示例：

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(27)
    }
}

Groovy DSL 大致等价于：

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(27)
    }
}

动手时注意什么

  • 第三方工具未必跟得上：官方明确举例，PMD 等工具目前还不一定支持 Java 27。升级后若静态分析、代码质量任务挂了，先查插件 / 工具链版本，而不是怀疑 Wrapper。
  • Daemon JDK ≠ Toolchain JDK：本机 JAVA_HOME 可以仍是 21/25，只要 Toolchain 能解析到 27；也可以反过来用 27 跑 Daemon、继续用较低版本 toolchain 编译存量模块。选哪边取决于团队镜像与 CI 镜像是否已装 27。
  • CI 要一起改：本地升了 Wrapper，流水线镜像里若没有可被 Toolchain 发现的 JDK 27（或没配 org.gradle.java.installations.* / 供应商自动下载策略），构建会在解析 toolchain 时失败。

说明：本文未在本地安装 JDK 27 并实测 Daemon 启动；以上能力描述以 9.8.0 release notes 为准。

复用 Maven Mirror：一处配置、两套构建工具

混用 Maven + Gradle、且公司有内部仓库镜像时，过去常要在 settings.xml 和 repositories { ... } / pluginManagement 各写一遍。9.8.0 提供开关：让 Gradle 读取 Maven 的 mirror 设置。

在项目或用户级 gradle.properties 中开启（默认关闭）：

org.gradle.mirror.maven.settings=true

开启后，Gradle 会按 Maven mirror 规则，替换匹配到的仓库 URL。官方说明覆盖范围包括：

  • 所有 HTTP/HTTPS 的 Maven 仓库
  • 构建脚本仓库，例如 gradlePluginPortal()
  • settings 里声明的仓库
  • 项目里声明的仓库

不支持 mirroring 的类型（官方列出）：

  • Ivy 仓库
  • Maven Local
  • Flat directory
  • 走 S3 / GCS 的 Maven 仓库

动手时注意什么

  • 先确认本机 / CI 的 Maven settings.xml 里 mirror 已经正确（mirrorOf、URL、认证）。Gradle 只是复用，不会替你修好坏的 Maven 配置。
  • 打开开关后，用 --info 或依赖洞察看一次实际解析到的仓库 URL，确认没有误伤到不该镜像的中央仓 / 插件门户（尤其是 mirrorOf=* 这类宽规则）。
  • 认证凭证仍按你们现有 Maven / Gradle 凭证机制走；mirror URL 变了，CI 密钥作用域是否覆盖新 host 要一并核对。
  • 更细的集中仓库说明见用户手册 Centralizing repositories（release notes 指向该节）。

说明：org.gradle.mirror.maven.settings 未在本地用真实 settings.xml 验证；行为与限制以官方 release notes 原文为准。

Windows：慢系统时钟场景的性能改进

Gradle 构建过程中会频繁读系统时钟（执行追踪、进度、日志时间戳）。在部分 Windows 机器——尤其是虚拟化环境上，读时钟本身很慢，累积后会拖垮构建。

9.8.0 会在启动时检测慢时钟，并在后续构建里切到更快的时间源：

  • 无需额外配置
  • 时钟正常的机器不受影响
  • 受影响机器上，官方称构建可快至约 45%（以 release notes 数字为准）

若你的 Windows CI / 开发机以前「莫名慢」，升到 9.8.0 后值得对比一次干净构建耗时；不必为此单独改 gradle.properties。

顺带有用、但不是本次主线的点

若升级时顺手扫一眼 release notes，还有几项偏工程效率的改动（本文不展开操作步骤）：

  • Copy / Sync 新增 incubating 的 destinationDirectory（DirectoryProperty），便于懒解析与任务依赖串联
  • GenerateMavenPom 参与 up-to-date：POM 未变时可 UP-TO-DATE；注册了 withXml 时仍会跳过输入追踪
  • CLI 问题报告：源码位置可点击、失败问题按出现顺序输出；Problems API 覆盖面扩大

需要这些能力时，直接查 9.8.0 release notes 对应小节即可。

建议落地顺序（可复制检查清单）

  1. 分支上执行 Wrapper 升级到 9.8.0，跑一次现有 CI / 本地 ./gradlew build（先不换 Java 27）。
  2. 对照 9.x upgrade guide，处理弃用警告。
  3. 若目标是 Java 27：先在 Toolchain 指定 27，再视情况把 Daemon / CI 镜像升到 27；逐个验证 PMD、SpotBugs、Kotlin、Android 等插件。
  4. 双构建工具团队：在测试项目打开 org.gradle.mirror.maven.settings=true，对比依赖下载 host 是否符合预期，再推广到全仓。
  5. Windows 慢构建机器：记录升级前后耗时，确认是否吃到时钟优化。

参考

— 感谢阅读 —
# java

一起交流

分享你的思考，让讨论更进一步。