Serguey Asael Shinder: Gradle 9.8 can reuse Maven's mirror settings, and the switch is off by default
Gradle 9.8.0 was released on 24 September. The headline items in the release notes are Java 27 support for both the daemon and toolchains, and something I have wanted in mixed shops for years: Gradle can now reuse Maven's mirror repository settings.
The mirror feature is opt-in. You enable it with org.gradle.mirror.maven.settings=true in gradle.properties, and from then on Gradle replaces a repository's URL whenever it matches a mirror configured for Maven. That applies to every HTTP or HTTPS Maven repository, including gradlePluginPortal() and repositories declared in settings or in projects. It does not apply to Ivy repositories, Maven local, flat directories, or Maven repositories served from S3 or GCS.
Why it matters: in an organisation with an internal proxy, the mirror is usually configured once for Maven and then configured again, slightly differently, for Gradle. Two descriptions of the same thing drift. The day someone changes the proxy host, one build tool follows and the other quietly keeps going to the old address, or to the public internet. Letting Gradle read the Maven configuration removes the second copy. Because the flag defaults to off, nothing changes until you set it, which is the right choice for a behaviour that rewrites repository URLs.
The release notes also warn that some third-party tools, PMD among them, do not yet support Java 27, so moving the daemon to 27 is a separate decision from compiling with it.
The item I would read even if you do not use Groovy is in Groovydoc. Groovydoc parses Java sources mixed into Groovy projects with JavaParser, and when the parser assumes a language level older than the code, modern constructs such as switch expressions, sealed classes and records fail to parse - and, in the notes' own words, the affected classes are silently omitted from the generated documentation. The new javaVersion property passes the language level through. It requires Groovy 4.0.27 or later, and on earlier versions it is silently ignored.
That second "silently" is the pattern worth noticing. A documentation build that drops classes it cannot parse still succeeds, and a configuration option ignored on an older version still looks applied. If you rely on Groovydoc, count the documented classes before and after the upgrade; it is the only check that would have caught the omission in the first place.
Smaller changes in 9.8: printed problem locations such as build.gradle.kts:8 are clickable in terminals that support hyperlinks, Copy and Sync gain a lazy destinationDirectory property, and dependency resolution failures now reach the Problems API with RFC 9457 details.