Gradle 9.8: Java 27 Toolchain, Maven Mirror, 45% Speedup

Gradle 9.8.0 landed September 29 and brings three concrete improvements worth acting on: it is the first Gradle release to officially support Java 27 toolchains, it can now inherit your Maven mirror configuration directly from settings.xml, and it fixes a years-old clock-reading bottleneck that was quietly inflating build times by up to 45% on Windows CI agents. If you run builds on GitHub Actions Windows runners or Azure DevOps, this upgrade pays for itself in the first run.

Java 27 Toolchain Support: What You Need to Do

JDK 27 went GA on September 15. Gradle 9.8 is the minimum version that officially supports running the Gradle daemon on JDK 27 and using it as a toolchain target. If you try to set languageVersion = JavaLanguageVersion.of(27) on an older wrapper, expect an unsupported Java version error.

Configuring it is the same as any toolchain:

// build.gradle.kts
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(27)
    }
}

The JDK 27 upgrade itself is worth the effort: compact object headers are now on by default (10–20% heap reduction for most apps), G1 replaces the old GC defaults across all environments, and post-quantum ML-KEM key encapsulation is baked into TLS 1.3. Those are not small gains for production services.

One gotcha to check before you flip the switch: some static analysis plugins lag behind new Java versions. PMD 7.27.0 (released August 28) is the first version with Java 27 support — if you are on an older PMD release, builds will fail at the analysis step. Verify your plugin versions before targeting JDK 27.

The Windows Speedup No One Is Talking About

This is the change that most coverage will underplay. Gradle reads the system clock a large number of times per build — every trace event, progress notification, and log message carries a timestamp. On bare-metal machines this is imperceptible. On virtualized Windows hosts — Azure DevOps hosted agents, GitHub Actions Windows runners, AWS CodeBuild Windows — the OS clock call can be an order of magnitude slower than on Linux, and the cost stacks up across thousands of calls.

Gradle 9.8 detects a slow system clock at startup and switches to an internal monotonic time source for the rest of that build. It requires zero configuration. Machines with a normal clock are completely unaffected. For teams on Windows CI, expect build time reductions up to 45%. For a 10-minute build, that is potentially four minutes back per run, every run.

There is no action required beyond upgrading the wrapper. But it is a solid reason not to skip this release and wait for 9.9.

Maven Mirror Reuse: One Config Instead of Two

Enterprise shops running Nexus or Artifactory know this problem: you configure the internal mirror URL in Maven’s ~/.m2/settings.xml, then configure it again in Gradle’s repository declarations. When the mirror URL changes, you update both. When you add a service account, you update both.

Gradle 9.8 adds opt-in support for reading Maven’s existing mirror configuration:

# gradle.properties
org.gradle.mirror.maven.settings=true

With that flag set, Gradle substitutes matching repository URLs with their mirrored equivalents from your Maven settings file. It applies to all HTTP/HTTPS Maven repositories, including gradlePluginPortal(), settings-level repos, and project repos. What it does not cover: Ivy repositories, mavenLocal(), flat directory repos, and anything served over S3 or GCS. For the common case of mirroring Maven Central through an internal proxy, this removes the duplication entirely.

One Breaking Change to Watch For

The Configuration Cache behavior for task logging listeners changed in 9.8. If your build or a plugin registers listeners on a task’s logging output during configuration — via addStandardOutputListener() or addStandardErrorListener() — those listeners are now stored in the Configuration Cache. Previously they were silently dropped on a cache hit.

The new behavior is more correct, but a listener that cannot be serialized now surfaces as a Configuration Cache problem instead of silently disappearing. This can turn a previously green build red after upgrading. If you hit it, the temporary opt-out is:

# gradle.properties — temporary workaround
org.gradle.configuration-cache.unsafe.skip-task-logging-listeners-serialization=true

That flag restores the old (silent-drop) behavior. It is explicitly marked as temporary and will be removed in a future release — use it to unblock the upgrade, then fix the listener properly.

How to Upgrade

Update your wrapper with:

./gradlew wrapper --gradle-version 9.8.0 --distribution-type all

Run that command twice. The first pass updates the wrapper properties file. The second regenerates the wrapper JAR and scripts using Gradle 9.8.0 itself. After upgrading, run your build and check for Configuration Cache failures. If you are targeting JDK 27, verify your static analysis plugins. Add org.gradle.mirror.maven.settings=true to gradle.properties if you use a shared repository proxy.

The Bottom Line

Gradle 9.8 is not a headline release — there is no new DSL, no major architecture shift. But the Windows speedup is real and genuinely underrated. If your team runs CI on Windows and you skip this upgrade, you are leaving build minutes on the floor for no reason. The Java 27 toolchain support is mandatory for anyone targeting the new JDK. And the Maven mirror feature quietly saves time for anyone maintaining both Maven and Gradle builds in the same organization.

Full details are in the Gradle 9.8.0 release notes. The upgrading within 9.x guide covers every deprecation and breaking change. If you are planning the JDK 27 move, the OpenJDK 27 project page has the full JEP list.