Gradle Release Notes

Upgrade instructions

Switch your build to use Gradle 9.8.0 by updating the wrapper in your project:

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

See the Gradle 9.x upgrade guide to learn about deprecations, breaking changes, and other considerations when upgrading to Gradle 9.8.0.

For Java, Groovy, Kotlin, and Android compatibility, see the full compatibility notes.

New features and usability improvements

Support for Java 27

With this release, Gradle supports Java 27.

You can now run the Gradle daemon on Java 27, in addition to using Java 27 via toolchains:

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

Some third-party tools (for example, PMD) do not yet support Java 27.

See the compatibility documentation for more details.

Reusing mirror settings from Maven

In organizations that use both Maven and Gradle build tools with an internal repository mirror, Gradle 9.8.0 supports reusing Maven's mirror repository settings with a simple flag.

By default, this is disabled, but you can enable it with org.gradle.mirror.maven.settings=true in gradle.properties.

When applying the mirror configuration, Gradle will replace a repository's URL if it matches any configured mirrors. This applies to all HTTP/HTTPS Maven repositories, including build script repositories like gradlePluginPortal(), repositories declared in settings, and repositories declared in projects. Ivy repositories, Maven local, flat directory repositories, and Maven repositories served over S3 or GCS do not support mirroring.

See the Centralizing Repositories section in the Gradle User Manual for more details.

CLI, logging, and problem reporting

Gradle provides an intuitive command-line interface, detailed logs, and a structured problems report that helps developers quickly identify and resolve build issues.

Easier to read problem reports

Two improvements make reported problems easier to scan and act on:

• Printed problem locations (demo-convention.gradle.kts:8) are now clickable in terminals that support hyperlinks, so you can jump straight to the source line in most modern IDEs and editors.
• Problems in the CLI failure output now appear in the order they occurred, which preserves the causal sequence when you scroll through a failing build.

Interactive HTML problem report

In the HTML problem report, the copy button stays visible while you scroll long stack traces, so capturing a full trace no longer means hunting for the button:

Broader coverage from the Problems API

Consumers of the Problems API now receive data from more parts of Gradle.

Dependency management failures are reported through the API with RFC 9457 details. Unresolved dependencies and configuration conflicts now surface as structured problems.

Configuration Cache warn-mode messages are also reported through the API, matching how Configuration Cache errors are already surfaced.

Problems raised from threads without a current build operation are now captured rather than dropped. This closes a gap where asynchronous work could silently lose its diagnostics.

Build authoring improvements

Gradle provides rich APIs for build engineers and plugin authors, enabling the creation of custom, reusable build logic and better maintainability.

Lazy destination directory for Copy and Sync

The Copy and Sync tasks only exposed the destination as destinationDir, a plain File property, so a destination derived from a provider had to be resolved eagerly at configuration time. Both tasks now expose a destinationDirectory DirectoryProperty:

tasks.register<Copy>("copyFiles") {
    from("src")
    destinationDirectory = layout.buildDirectory.dir("out")
}

The property is the single source of truth for the destination. Assigning it is equivalent to calling into(...), and it reflects whatever was configured through into(...) or destinationDir.

into(...) now wires a Provider destination into destinationDirectory instead of resolving its value, so provider-based destinations stay lazy; all other notations (String, File, Closure, Callable, ...) keep their existing lazy resolution. Since destinationDirectory is a task output property, other tasks can consume it directly and pick up the task dependency.

The new property is incubating. destinationDir continues to work and will be deprecated once destinationDirectory is promoted.

See Copy.destinationDirectory and Sync.destinationDirectory in the DSL Reference for more details.

Groovydoc supports modern Java sources and Groovy 6 output options

The Groovydoc task now exposes configuration options that had previously only been available through the Groovy CLI, Ant task, or Maven plugin, closing a long-standing gap in Gradle's Groovydoc support.

Java source parsing level: Groovydoc uses JavaParser to read Java sources mixed into Groovy projects. When the parser's assumed language level is older than the sources, modern constructs — switch expressions, sealed classes, records, and similar — fail to parse, and the affected classes are silently omitted from the generated documentation. The new javaVersion property forwards the language level to Groovydoc so those sources parse cleanly:

tasks.groovydoc {
    javaVersion = JavaLanguageVersion.of(21)
}

This option requires Groovy 4.0.27 or later and is silently ignored on earlier Groovy versions.

Groovy 6.0.0 documentation options: For projects using Groovy 6.0.0 or later, several new properties are now available on the Groovydoc task to control the generated output:

All of these are silently ignored on earlier Groovy versions, so they are safe to configure in builds that may be run against multiple Groovy releases.

All new properties are incubating.

See the Groovydoc task in the DSL Reference for the full list of configuration options.

Core plugin and plugin authoring enhancements

Gradle provides a comprehensive plugin system, including built-in Core Plugins for standard tasks and powerful APIs for creating custom plugins.

Up-to-date checks for POM generation in Maven publishing

The GenerateMavenPom task was previously marked as untracked, so it executed on every build regardless of whether the underlying POM had changed.

The task now declares each part of its source POM as a task input, so it participates in up-to-date checks:

$ ./gradlew generatePomFileForMavenPublication
> Task :generatePomFileForMavenPublication UP-TO-DATE

BUILD SUCCESSFUL

When a withXml action is registered, task input tracking remains disabled, as withXml actions do not yet support snapshotting, so the task continues to run on every build. To restore up-to-date behavior, move the customization into the DSL properties on MavenPom where possible.

See the Generate POM task section in the Gradle User Manual for more details.

Declaring plugin compatibility with Isolated Projects on the Plugin Portal

The Plugin Publish Plugin now allows plugin authors to declare support for Isolated Projects using the compatibility { features { ... } } block:

gradlePlugin {
    plugins {
        create("myPlugin") {
            id = "io.github.my.plugin"
            // ...
            compatibility {
                features {
                    isolatedProjects = true
                    configurationCache = true
                }
            }
        }
    }
}

Declaring compatibility with Gradle features can surface badges on the Plugin Portal and improve your plugin's search ranking.

Publishing a plugin without a compatibility declaration is deprecated as of com.gradle.plugin-publish 2.2.1 and produces a warning.

See the Declaring compatibility with Gradle features section in the Gradle User Manual for more details.

Performance improvements

Gradle continues to reduce build times and memory usage across the daemon, configuration, and execution phases.

Improved performance on Windows machines with slow system clocks

Builds on affected Windows machines are up to 45% faster in this release.

Gradle reads the system clock frequently while a build runs, to capture execution traces, progress events, and log messages. On most machines, this is inexpensive, but on some Windows systems, particularly virtualized ones, reading the clock is much slower, and the cost accumulates over the many readings taken during a single build.

Gradle now detects a slow system clock at startup and switches to a faster time source for the rest of the build. No configuration is required, and builds on machines with a normal system clock are unaffected.

Documentation and training

Documentation

The User Manual reference pages for the core plugins have been entirely rewritten for consistency and depth. The Core Plugin Reference index has also been reorganized and now lists previously missing core plugins.

Two new entries have been added to the Best Practices collection:

• Obtain Loggers via Logging.getLogger(Class) outside of Tasks — where and how to acquire a logger in build logic.
• Favor collection property types over a Property holding a collection — the case for ListProperty and SetProperty over Property<List<...>>.

Fixed issues

Known issues

Known issues are problems that were discovered post-release that are directly related to changes made in this release.

External contributions

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

Reporting problems

If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure if you're encountering a bug, please use the forum.

We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.