# Gradle Release Notes

We are excited to announce Gradle 9.2.0 (released 2025-11-11).

This release introduces support for running Gradle on Windows ARM (ARM64) devices, making it easier to build on ARM-based systems.

It also improves the publishing API with new ways to define and publish custom software components.

Additionally, there are error and warning reporting improvements, including better suggestions when dependency verification fails, and new task grouping for Antlr.

The Daemon toolchain feature has been promoted to stable.

We would like to thank the following community members for their contributions to this release of Gradle: Adam, Björn Kautler, hasunzo, HYEON, Hyunjoon Park, HYUNJUN SON, Jendrik Johannes, Kirill Gavrilov, Madalin Valceleanu, Martin Bonnin, Matthew Haughton, Mikhail Polivakha, Na Minhyeok, Philip Wedemann, Philipp Schneider, Róbert Papp, Simon Marquis, TheGoesen, Vincent Potucek, Xin Wang.

Be sure to check out the public roadmap for insight into what's planned for future releases.

## Table Of Contents

## Upgrade instructions

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

    ./gradlew wrapper --gradle-version=9.2.0 && ./gradlew wrapper

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

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

## New features and usability improvements

### Windows on ARM support

Gradle now supports running builds on Windows on ARM (ARM64/AArch64) devices.

This makes it possible to run Gradle on Windows virtual machines hosted on ARM-based systems.

NOTE: Due to compatibility issues on Windows AArch64, the rich console is not available. Both the default behavior and `--console=rich` fall back to plain console output.

Limitations are listed in Known issues

### Performance Improvements

#### Shorter time to first task execution

Gradle 9.2.0 is more efficient at building its internal work graph. This means tasks, like running a test, for example, will start executing sooner compared to previous Gradle versions.

The effect is more apparent when there's a Configuration Cache hit since (re)building the work graph is a very significant part of the work leading to task execution.

The observed improvement will vary depending on the size, complexity and inputs associated with the work graph. Our experiments have shown up to 40% shorter times to first task execution in large builds with thousands of modules and complex dependency graphs.

Here are the numbers for different scenarios we have measured, with charts comparing 10 `--dry-run` executions against Gradle 9.1.0:

- 34% on the `gradle/gradle` build running `codeQuality`, a work graph with 10868 tasks across 217 projects
- 42% on a synthetic large Java build running `compileJava`, a work graph with 8190 tasks across 8190 projects
- 11% on a synthetic Android build running `assembleDebug`, a work graph with 21499 tasks across 526 projects

#### Lower memory usage

Due to optimized data structures, Gradle 9.2.0 uses less memory compared to Gradle 9.1.0. In our experiments, the improvements vary from 7% to 12% less memory required for the same workloads.

### Publishing improvements

Gradle provides APIs for plugin authors and build engineers to define and customize the software components their project produces when publishing them.

#### New `PublishingExtension.getSoftwareComponentFactory()` method

Gradle now exposes the `SoftwareComponentFactory` service directly through the `publishing` extension. This makes it easier to create and publish custom components.

In most builds, a publishable component is already available. For example, the Java plugins automatically provide a `java` component. But if you’re authoring a plugin and want to publish something custom without depending on the Java plugins, this new method provides a straightforward way to do so:

    plugins {
        id("maven-publish")
    }

    val consumableConfiguration: Configuration = getAConfiguration()

    publishing {
        val myCustomComponent = softwareComponentFactory.adhoc("myCustomComponent")
        myCustomComponent.addVariantsFromConfiguration(consumableConfiguration) {}

        publications {
            create<MavenPublication>("maven") {
                from(myCustomComponent)
            }
        }
    }

#### New provider-based methods for publishing configurations

Two new methods have been added to `AdhocComponentWithVariants` that accept providers of consumable configurations:

- `void addVariantsFromConfiguration(Provider<ConsumableConfiguration>, Action<? super ConfigurationVariantDetails>)`
- `void withVariantsFromConfiguration(Provider<ConsumableConfiguration>, Action<? super ConfigurationVariantDetails>)`

These complement the existing overloads that require an already realized configuration.

By accepting providers, configurations can now stay lazy and are only realized when needed for publishing:

    plugins {
        id("base")
        id("maven-publish")
    }

    group = "org.example"
    version = "1.0"

    val myTask = tasks.register<Jar>("myTask")
    val variantDependencies = configurations.dependencyScope("variantDependencies")
    val myNewVariant: NamedDomainObjectProvider<ConsumableConfiguration> = configurations.consumable("myNewVariant") {
        extendsFrom(variantDependencies.get())
        outgoing {
            artifact(myTask)
        }
        attributes {
            attribute(Category.CATEGORY_ATTRIBUTE, objects.named<Category>("foo"))
        }
    }

    publishing {
        val component = softwareComponentFactory.adhoc("component")
        // New overload accepts a provider instead of a realized configuration
        component.addVariantsFromConfiguration(myNewVariant) {}

        repositories {
            maven {
                url = uri("<your repo url>")
            }
        }
        publications {
            create<MavenPublication>("myPublication") {
                from(component)
            }
        }
    }

With this approach, `myNewVariant` is only realized if the `myPublication` publication is actually published.

### Error and warning reporting improvements

Gradle provides a rich set of error and warning messages to help you understand and resolve problems in your build.

#### Improved suggestion when dependency verification fails

Gradle’s dependency verification helps you mitigate security risks by ensuring downloaded artifacts match expected checksums or are signed with trusted keys.

When you disable key servers in `gradle/verification-metadata.xml` using `<key-servers enabled="false"/>` and a verification failure occurs due to missing keys, Gradle now adds the `--export-keys` parameter to suggested commands:

### Antlr task grouping improvements

Antlr-related tasks such as `generateGrammarSource` and `generateTestGrammarSource` are now grouped under `Antlr` in Gradle’s task listings.

Previously, these tasks appeared in the default `Other tasks` group, which only shows when running `./gradlew tasks --all`.
By assigning them to the `Antlr` group, they are easier to discover:

    $ ./gradlew tasks

    Antlr tasks
    -----------
    plugin:generateGrammarSource - Processes the main Antlr grammars.
    plugin:generateTestGrammarSource - Processes the test Antlr grammars.

## Promoted features

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backward compatibility. See the User Manual section on the "Feature Lifecycle" for more information.

The following are the features that have been promoted in this Gradle release.

### Daemon toolchain is now stable

The Daemon toolchain, introduced as an incubating feature in Gradle 8.8, has been improved and is now stable. It no longer prints an incubation warning when used.

## 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.