# The Gradle Blog

The Gradle Blog

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Testing Astra 6 v Fable 5.1 on a Gradle docs bug

DevFeed: [Testing Astra 6 v Fable 5.1 on a Gradle docs bug](<https://devfeed.tech/articles/testing-astra-6-v-fable-5-1-on-a-gradle-docs-bug-24700.md>)

Original publisher: [Read original article](<https://blog.gradle.org/two-agents-one-gradle-bug>)

Author: Laura Kassovic

Published: 2026-09-09T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [ai-coding](<https://devfeed.tech/topics/ai-coding.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [Fable](<https://devfeed.tech/topics/fable.md>), [Documentation](<https://devfeed.tech/topics/documentation.md>), [bug](<https://devfeed.tech/topics/bug.md>)

Tags: [ai-coding](<https://devfeed.tech/tags/ai-coding.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [bug](<https://devfeed.tech/tags/bug.md>), [docs](<https://devfeed.tech/tags/docs.md>), [fable](<https://devfeed.tech/tags/fable.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [testing](<https://devfeed.tech/tags/testing.md>)

### AI overview

An engineering blog compares Astra 6 and Fable 5.1 after each agent fixes the same Gradle Kotlin DSL documentation bug. Both fixes passed independent judging, while the comparison examines cost, speed, and maintainability. The author emphasizes that the result is based on one run per model, one judge, and one bug.

### Source excerpt

On the afternoon of September 7th, claude-fable-5-1 was handed a git repository, a GitHub issue, and fifty turns to fix it. Just over three hours later, gpt-6-astra finished the same assignment in another worktree. Same issue. Same constraints. Different CLI wrapped around each model: claude-code for Fable, codex for Astra. Both Agents fixed the bug. Both results were graded as successes by an independent judge. But these results were quite different. You would be forgiven for wondering why an engineering blog is running a two-model bakeoff on a single documentation bug, in a year when everybody and their intern has published an AI coding benchmark. Here's the honest answer: we wanted to know which one actually did the better job, as a side quest of the Agentic Gradle project. But "better" was never going to mean pass-or-fail. Both of these agents passed; if that were the whole story, this post would be four sentences long. What actually separates a fix worth merging from a fix worth sending back is cost, speed, and whether the result is something we would want to maintain, and those three do not all point the same direction, as you are about to see. So: one bug, two agents, and a very literal stopwatch. Here is what this looks like when you actually read the agents' transcripts. Real talk up front: this is n=1. One run per model, one judge, one bug. That's a thin base for anything you'd call a leaderboard, and I'll say so again at the end, but it didn't stop me from landing on an opinion by the time I'd finished reading both transcripts. The bug, briefly Issue #34751, filed August 21st by our very own cobexer, is the kind of bug that is very easy to describe and mildly annoying to fix. In the Kotlin DSL API docs, a type like Attribute<Integer> linked to the Java 21 Javadoc. It should have linked to Java 17, because Gradle targets Java 17. The reason is almost embarrassingly mundane once you see it. Gradle is built with a JDK 21 toolchain but targets JDK 17, which i

## Introducing the Gradle Security Subscription

DevFeed: [Introducing the Gradle Security Subscription](<https://devfeed.tech/articles/introducing-the-gradle-security-subscription-24634.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-security-subscription>)

Author: Gradle Build Tool

Published: 2026-08-31T04:00:00Z

Content type: release

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Security](<https://devfeed.tech/topics/security.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [Vulnerabilities](<https://devfeed.tech/topics/vulnerabilities.md>)

Tags: [gradle](<https://devfeed.tech/tags/gradle.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [releases](<https://devfeed.tech/tags/releases.md>), [security](<https://devfeed.tech/tags/security.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>), [vulnerabilities](<https://devfeed.tech/tags/vulnerabilities.md>)

### AI overview

Gradle announces the Gradle Security Subscription, which provides security fixes under a service-level agreement, maintenance for Gradle versions beyond the open source end-of-life policy, and advance notice of newly discovered vulnerabilities. The article explains build-tool security risks and argues that the subscription does not change the open source community offering.

### Source excerpt

The Gradle Security Subscription is available today. It provides security fixes under a service-level agreement, security maintenance for Gradle versions beyond the open source end-of-life policy, and advance notice of newly discovered vulnerabilities ahead of public disclosure. Coverage details are on our subscription page. The rest of this post explains why the subscription is important and what changes for the open source community (in short, nothing). The toolchain as an attack surface In 1984, while accepting the Turing Award, Ken Thompson described a compiler he had modified to insert a backdoor into the programs it compiled. Reviewing the source of the affected program revealed nothing. And reviewing the source of the compiler revealed nothing either. His conclusion was that you cannot fully trust code you did not create entirely yourself. Four decades later, we find ourselves facing the same dilemma. Software composition analysis scans the dependencies a project declares. Static analysis scans the source a team writes. But neither examines the build tool that turns that source and those dependencies into the artifact that goes to production. This gap has been exploited repeatedly. In 2015, XcodeGhost distributed a modified version of Apple's IDE that inserted malicious code into every application compiled with it, reaching thousands of App Store applications whose developers had written nothing malicious. In 2020, SolarWinds released a compromised version of their IT software, but the attackers modified no source code. They gained access to the build environment and installed malware that monitored the compilation process, injecting a backdoor into the resulting binary as it was produced. Approximately 18,000 organizations installed the signed update, including the U.S. Departments of Treasury, State, Defense, and Homeland Security. There are two more recent incidents. The Codecov Bash Uploader compromise ran undetected for roughly two months in 2021, exfilt

## Gradle Is Going Agentic

DevFeed: [Gradle Is Going Agentic](<https://devfeed.tech/articles/gradle-is-going-agentic-24627.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-is-going-agentic>)

Author: Laura Kassovic

Published: 2026-08-19T04:00:00Z

Content type: opinion

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Cache](<https://devfeed.tech/topics/cache.md>)

Tags: [agentic](<https://devfeed.tech/tags/agentic.md>), [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [cache](<https://devfeed.tech/tags/cache.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [context-window](<https://devfeed.tech/tags/context-window.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [tooling](<https://devfeed.tech/tags/tooling.md>)

### AI overview

Gradle describes Agentic Gradle, a project focused on helping agents use Gradle effectively. It plans to provide official Gradle skills and add Gradle features for build workflows that agents make more difficult, supported by repeatable benchmarking scenarios.

### Source excerpt

More and more of the people who run Gradle every day aren't typing ./gradlew build themselves. They're asking an agent to run a build, paste it the failure, then ask it to fix the thing that failed. The agent is now part of the build loop, whether the build tool invited it or not. This is not a Gradle-specific oddity. Every build tool is being driven by a new kind of user: not a person with muscle memory for flags and log output, but a model with a terminal, a context window, and alarming confidence. New user, new failure modes. We have hit enough of them that pretending this is temporary started to feel silly. So we started a project. We're calling it Agentic Gradle. The practical version has two buckets: skills that teach agents how to use Gradle effectively, and new Gradle features for the places where agents make today's build tooling awkward. Not because Gradle is bad at this, but because agents push builds in ways we never had to support before. Picking it up meant we didn't do something else this cycle. We'll get to that, because it is the more interesting part of the story. But first, what we're actually building. What this looks like in practice There are three pieces, in the order we're putting real time behind them. Official Gradle skills. A skill is a small, focused set of instructions that teaches an agent how to do something specific with Gradle: read a build failure, run the right task, understand what a Build Scan is telling it. Skills also make vague prompts less dangerous. Give an agent "speed up my build" and, left to its own devices, it'll reach for whatever pattern it saw most often on the internet, which is often years out of date. A focused Gradle performance Skill can keep it closer to the boring advice that works: enabling the configuration cache, reaching for a version catalog, avoiding configuration-time anti-patterns it wouldn't otherwise think to check. We've been experimenting with these throughout the year, and a few are close to ready

## Resilient Sync: Your IDE Keeps Helping even when your Build is Broken

DevFeed: [Resilient Sync: Your IDE Keeps Helping even when your Build is Broken](<https://devfeed.tech/articles/resilient-sync-your-ide-keeps-helping-even-when-your-build-is-broken-24686.md>)

Original publisher: [Read original article](<https://blog.gradle.org/resilient-sync>)

Author: Laura Kassovic

Published: 2026-08-13T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [IntelliJ IDEA](<https://devfeed.tech/topics/intellij-idea.md>), [ide](<https://devfeed.tech/topics/ide.md>), [2026.2](<https://devfeed.tech/topics/2026-2.md>), [configuration](<https://devfeed.tech/topics/configuration.md>)

Tags: [2026-2](<https://devfeed.tech/tags/2026-2.md>), [autocomplete](<https://devfeed.tech/tags/autocomplete.md>), [build](<https://devfeed.tech/tags/build.md>), [feature](<https://devfeed.tech/tags/feature.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [ide](<https://devfeed.tech/tags/ide.md>), [intellij-idea](<https://devfeed.tech/tags/intellij-idea.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [upgrade](<https://devfeed.tech/tags/upgrade.md>)

### AI overview

Gradle 9.7 and IntelliJ IDEA 2026.2 introduce resilient sync, allowing the IDE to remain useful when parts of a Gradle build fail to configure. Instead of aborting the entire sync, Gradle provides partial project models, editor data for resolvable Kotlin DSL scripts, and structured failure information.

### Source excerpt

You upgrade Gradle, hit sync, and watch every build script turn red. The IDE that was finishing your sentences five minutes ago suddenly has nothing to say, and you're left fixing build logic in what is effectively a very expensive text editor. And the API you need to fix the error is the exact API the IDE can no longer tell you anything about. To get autocomplete back, fix the build. To fix the build, it would help to have autocomplete. Chicken, meet egg. Gradle 9.7, together with IntelliJ IDEA 2026.2, fixes this. The feature is called resilient sync, and it is one of those changes you only notice by its absence once you have it. What goes wrong today Nobody designed the old behavior to be cruel. It falls out of two entirely reasonable decisions that happen to collide. The IDE reasons that if it cannot get a model back from Gradle, it has nothing accurate to show you, so it shows almost nothing. Gradle reasons that if configuration throws, the whole operation failed, so it reports the failure and stops. Both are correct. Together they produce a tool that abandons you precisely when you need it most. The worst version is the multi-project build. You have a hundred subprojects, and one of them (or one shared convention plugin in an included build) has a broken script. In the old world, that single failure takes down the sync for all one hundred. Ninety-nine healthy projects lose their IDE support over one bad line somewhere else in the tree. Power users had a workaround, as charming as workarounds usually are: # The old "please just give me some completion" incantation. Don't rely on this. org.gradle.jvmargs=-Dorg.gradle.kotlin.dsl.provider.mode=classpath It coaxed some completion out of a broken build, frequently broke Gradle's internal state in other ways, and often needed an IDE restart to load new API. Reader, it was not a fix. It was a coping mechanism. What is resilient sync? Resilient sync replaces all-or-nothing with best-effort. When part of your build fails

## Gradle's CI bot summarizes Develocity test failures on pull requests

DevFeed: [Gradle's CI bot summarizes Develocity test failures on pull requests](<https://devfeed.tech/articles/the-red-x-that-says-what-it-saw-24615.md>)

Original publisher: [Read original article](<https://blog.gradle.org/dogfooding-failure-summaries>)

Author: Laura Kassovic

Published: 2026-08-11T04:00:00Z

Content type: opinion

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [ci](<https://devfeed.tech/topics/ci.md>), [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Caching](<https://devfeed.tech/topics/caching.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [ci](<https://devfeed.tech/tags/ci.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>)

### AI overview

The article describes a Gradle CI bot that reads failures from Develocity, groups related failures, and posts concise summaries on pull requests. A documented example shows the summary identifying a test that unexpectedly passed despite being marked as expected to fail under Configuration Cache.

### Source excerpt

A failing CI check knows exactly what went wrong. It was there. It watched the exception get thrown, caught the stack trace, wrote the whole thing down. And then, by long tradition, it tells you almost none of it: a red X, a job name, and an invitation to go read the logs yourself. Our CI bot has commented on pull requests in gradle/gradle for years: triggering builds on request, shepherding the merge queue, answering commands. In mid-July we gave it one more job. When a check goes red, it reads the failures out of Develocity, groups them, and posts a short summary on the pull request, so the red X finally has to say what it saw. A real failure Take pull request #38047, a change that gives the Copy and Sync tasks a lazy destinationDirectory property. Additive, non-breaking, the kind of change you expect to sail through. Most of its checks came back green. One did not. Here is what the bot left on the pull request: You can read the entire shape of the failure without opening anything. It is a single test, named in full: CachedTaskActionIntegrationTest, the case "ad hoc tasks with the same action share results," in :core:configCacheIntegTest. And it is the good kind of surprising. The test was marked to be fixed: a known limitation, annotated as expected to fail under the Configuration Cache. Except it did not fail. It passed. Expected the test to fail in 'Configuration Cache' mode, but it succeeded! The change had quietly fixed something a stale annotation still insisted was broken, and the build stopped to point it out. The comment links straight into the Build Scan. Open it, and the failure is waiting on the summary: That is the Build Scan for the failing build, and the failure is sitting right in the summary: the same test named again, the ToBeFixedUnexpectedSuccessException spelled out, and, because this is Develocity, the test's own history next to it: 713 runs in the last seven days, 536 passed, 7 failed. The comment is the headline. The Build Scan is the story

## Introducing Isolated Projects

DevFeed: [Introducing Isolated Projects](<https://devfeed.tech/articles/introducing-isolated-projects-24653.md>)

Original publisher: [Read original article](<https://blog.gradle.org/introducing-isolated-projects>)

Author: Alex Semin

Published: 2026-08-06T04:00:00Z

Content type: release

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [releases](<https://devfeed.tech/topics/releases.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>)

Tags: [configuration](<https://devfeed.tech/tags/configuration.md>), [feature](<https://devfeed.tech/tags/feature.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [make](<https://devfeed.tech/tags/make.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [releases](<https://devfeed.tech/tags/releases.md>)

### AI overview

Gradle introduces Isolated Projects, a performance feature that isolates projects during the configuration phase so they can be processed independently and concurrently. In Gradle 9.7.0, the feature moves from experimental to incubating, with current gains primarily from parallel project configuration.

### Source excerpt

Isolated Projects is a Gradle performance feature that speeds up the configuration phase. When the feature is enabled, each project in a build becomes "isolated" from others via boundaries that cannot be crossed. With this guarantee, Gradle can safely operate on each project independently and concurrently. This enables greater utilization of machine resources at configuration time and sets the stage for future caching optimizations. In the latest Gradle 9.7.0 release, Isolated Projects graduates from experimental to incubating. We believe Isolated Projects is the future of Gradle, and we intend to stabilize it and eventually make it the default. In this Gradle version, most of the performance gains come from parallel project configuration. It is not the only optimization these isolation constraints make possible, just the first to ship. It provides speedups across practically all scenarios, including CLI invocations and IDE sync. We invite everyone to try it and share feedback. Adopting Isolated Projects Isolated Projects ships with an extensive guide to adopting it. If you've already upgraded to Configuration Cache, which is a prerequisite, then the process should be familiar. You can enable the feature either via the --isolated-projects command-line flag or with the property org.gradle.isolated-projects=true. It must be enabled with a property to take effect for IDE sync. # gradle.properties org.gradle.isolated-projects=true When Isolated Projects is enabled, it takes precedence over other performance features. You can learn more about how it interacts with other features in this section of the documentation. Since the feature introduces new isolation constraints, you might have to adjust your build logic or upgrade community plugins to take advantage of it. For correctness, Gradle will fail immediately upon encountering the first constraint violation and report the error: You can use the Diagnostics mode to discover many constraint violations at once. All the rep

## Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each)

DevFeed: [Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each)](<https://devfeed.tech/articles/three-gradle-talks-from-kotlinconf-2026-and-what-to-steal-from-each-24622.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-at-kotlinconf-2026>)

Author: Laura Kassovic

Published: 2026-07-28T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Groovy](<https://devfeed.tech/topics/groovy.md>), [ide](<https://devfeed.tech/topics/ide.md>), [Scripting](<https://devfeed.tech/topics/scripting.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [best-practices](<https://devfeed.tech/tags/best-practices.md>), [build](<https://devfeed.tech/tags/build.md>), [build-tool](<https://devfeed.tech/tags/build-tool.md>), [conference](<https://devfeed.tech/tags/conference.md>), [developer](<https://devfeed.tech/tags/developer.md>), [dsl](<https://devfeed.tech/tags/dsl.md>), [event](<https://devfeed.tech/tags/event.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [groovy](<https://devfeed.tech/tags/groovy.md>), [ide](<https://devfeed.tech/tags/ide.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlinconf](<https://devfeed.tech/tags/kotlinconf.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [script](<https://devfeed.tech/tags/script.md>), [scripting](<https://devfeed.tech/tags/scripting.md>), [talk](<https://devfeed.tech/tags/talk.md>), [talks](<https://devfeed.tech/tags/talks.md>)

### AI overview

The article reviews three Gradle talks from KotlinConf 2026. It explains the progression from Groovy build scripts to the Kotlin DSL and early Declarative Gradle, emphasizing the problems each approach addresses. It also introduces Gradle best practices for organizing and optimizing builds.

### Source excerpt

Every year I tell myself I'll watch every conference talk I missed. Every year I get through maybe three before a build breaks and I get pulled back into real life. KotlinConf is the one event where I actually follow through, partly because the talks are short and dense, and partly because a good chunk of my coworkers and friends are on stage. This year in Munich, three of them talked about Gradle: Paul Merlin on the history of our DSLs, Stefan Wolf on best practices, and Marcin Mycek on Declarative Gradle for Kotlin. I watched all three so you can decide which ones are worth your fifteen minutes. A Tale of the Gradle DSLs -- Paul Merlin Paul has been inside Gradle's DSL machinery for years, which makes him exactly the right person to tell this story and exactly the wrong person to pretend the early days were clean. The talk traces how build logic went from Groovy, to the Kotlin DSL, to Declarative Gradle. The useful part isn't the timeline. It's that each of those was solving a real problem the previous one couldn't. Groovy gave us a flexible, dynamic scripting language, which was great right up until you wanted your IDE to tell you what was valid. The Kotlin DSL brought static typing, real autocompletion, and refactoring that doesn't rely on hope. That's why the Kotlin DSL is now the default for new Gradle builds. Declarative Gradle is the next swing: describe what your build is rather than script how it runs. The honest through-line is that none of these fully replaces the last one. Kotlin DSL is where most people should be today. Groovy still runs an enormous amount of the world's build logic and isn't going anywhere fast. Declarative Gradle is early but points at where things are headed. Real talk: if your build scripts are still Groovy and still working, you don't have to panic-migrate this weekend. But if you're starting something new, reach for the Kotlin DSL and let the IDE carry some of the weight. 📺 Watch the talk 10 Gradle Best Practices Every Kotlin Deve

## How the Gradle Team Adopted Isolated Projects

DevFeed: [How the Gradle Team Adopted Isolated Projects](<https://devfeed.tech/articles/how-the-gradle-team-adopted-isolated-projects-24658.md>)

Original publisher: [Read original article](<https://blog.gradle.org/isolated-projects-in-gradle-team>)

Author: Alex Semin

Published: 2026-07-22T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Dependency management](<https://devfeed.tech/topics/dependency-management.md>), [ci](<https://devfeed.tech/topics/ci.md>), [ide](<https://devfeed.tech/topics/ide.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [ci](<https://devfeed.tech/tags/ci.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [dependency-management](<https://devfeed.tech/tags/dependency-management.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [ide](<https://devfeed.tech/tags/ide.md>), [parallelism](<https://devfeed.tech/tags/parallelism.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

The Gradle team describes adopting the experimental Isolated Projects feature in its own build. The article explains that Isolated Projects runs project configuration in parallel to improve scalability and performance, and outlines migration prerequisites, diagnostics, convention plugins, dependency management, and Shared Build Services.

### Source excerpt

Isolated Projects is an experimental feature aimed at improving Gradle scalability and performance. It speeds up builds by running project configuration in parallel, which benefits practically every workflow, from CI builds to IDE sync. We want the feature to offer an excellent user experience, so we made it a goal to adopt Isolated Projects in our own build, even though it is still in active development. This lets us find and smooth out the rough spots early, though secretly, we were also looking forward to the productivity boost for our own team. With Isolated Projects, more build logic runs concurrently. To keep builds reliable under that parallelism, the feature introduces additional constraints, and adopting it means migrating your build to address the violations of those constraints. Migrating our build Isolated Projects builds directly on top of the Configuration Cache, so making the build Configuration Cache compatible is a prerequisite. Fortunately for us, we've been enjoying fast inner developer loops for many years now, so that box was already checked. The general approach to migrating against new constraints is to start with the simplest workflows, such as running the help task, and address the violations. Then proceed to more complex workflows, such as IDE sync or CI. Running in Diagnostics mode helps you see all violations at once in a single HTML report, and the guide describes the recommended migration path. For the Gradle build, we followed a similar path. What helped us the most and made the migration much smoother is following the best practices, especially the best practice of having convention plugins: each project applies the build logic it needs, and no project has to reach in and mutate another's state directly. We've leaned heavily on sharing artifacts between projects only via dependency management, which is inherently compatible with Isolated Projects by making each project define its "outputs", on which other projects can depend. For more

## Gradle Technologies Renames Itself Develocity

DevFeed: [Gradle Technologies Renames Itself Develocity](<https://devfeed.tech/articles/the-company-formerly-known-as-gradle-24696.md>)

Original publisher: [Read original article](<https://blog.gradle.org/the-company-formerly-known-as-gradle>)

Author: Gradle Build Tool

Published: 2026-07-17T04:00:00Z

Content type: news

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [observability](<https://devfeed.tech/topics/observability.md>)

Tags: [announcement](<https://devfeed.tech/tags/announcement.md>), [company](<https://devfeed.tech/tags/company.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [open-source](<https://devfeed.tech/tags/open-source.md>)

### AI overview

Gradle Technologies renamed itself Develocity in June 2026. The Gradle Build Tool remains unchanged, free, open source, and Apache 2.0-licensed.

### Source excerpt

Names are like infrastructure. They mostly work invisibly, which means the rare occasions when they don't work generate confusion wildly out of proportion to the underlying facts. Our name has had a known bug, and we have finally shipped a fix. This post explains what changed, what emphatically did not, and why the word "Develocity" now appears near the word "Gradle" in places like search results and the header of this website. The short version, for people who close browser tabs quickly: our company renamed itself from Gradle Technologies to Develocity in June 2026. The build tool is not renamed, not acquired, not relicensed, and not changing hands. It remains free, open source, Apache 2.0-licensed, and at home right here at gradle.org. If your interest in corporate naming decisions is limited (a healthy instinct), you can stop reading now, and your builds will be entirely unaffected. For everyone else, some institutional mechanics (and an FAQ). One word, two referents In 2008, Hans Dockter started building a build tool and called it Gradle. Some years later, there was a company, and, following the extremely common pattern for companies formed around a successful open source project, it was also called Gradle. This works fine right up until the company starts doing things that are not the build tool, at which point every sentence containing the word "Gradle" acquires a footnote. We know this because we literally maintain that footnote: the fine print at the bottom of this website has said, for years, that "Gradle" on these pages means Gradle Build Tool and not Gradle, Inc. When a name requires a standing disclaimer to be parsed correctly, the name has a bug. The company side of the house has, for close to a decade, built a commercial product called Develocity: a universal toolchain & artifact observability platform that works with Gradle, and also with Maven, Bazel, npm, sbt, and other toolchains that are conspicuously not Gradle. (The free Build Scan service is po

## Triaging at Scale: How the Gradle Team Handles Issues and Pull Requests

DevFeed: [Triaging at Scale: How the Gradle Team Handles Issues and Pull Requests](<https://devfeed.tech/articles/triaging-at-scale-how-the-gradle-team-handles-issues-and-pull-requests-24699.md>)

Original publisher: [Read original article](<https://blog.gradle.org/triaging-gradle-github-issues>)

Author: Vlad Chesnokov

Published: 2026-07-16T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [issue tracker](<https://devfeed.tech/topics/issue-tracker.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [Automation](<https://devfeed.tech/topics/automation.md>), [pull-requests](<https://devfeed.tech/topics/pull-requests.md>)

Tags: [automation](<https://devfeed.tech/tags/automation.md>), [bug](<https://devfeed.tech/tags/bug.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [github](<https://devfeed.tech/tags/github.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [issue-tracker](<https://devfeed.tech/tags/issue-tracker.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [usability](<https://devfeed.tech/tags/usability.md>)

### AI overview

The Gradle team explains how it triages GitHub issues and pull requests at scale. The article describes lessons from using and then removing stale-issue automation, the role of human review, and how issue reports help identify bugs, documentation gaps, and usability problems.

### Source excerpt

Communities are at the heart of Gradle's success. Without their involvement, the build tool would not have the extensive feature set and wide use it has. And using the plural form is no mistake! While the user community is the largest, we also have a community of plugin authors that contribute to extending the capabilities of Gradle. A significant part of interactions between the Gradle team and those communities occurs via feature requests and bug reports using GitHub's issue tracker. Over the past years, we have improved how we handle those reports. We can now give them the attention they deserve and use them to help us improve the build tool across releases. In this post, we'll walk through how triage works today, the changes that got us here, and what you can do to help us help you when you report an issue. An iterative process Back in 2020, we introduced a stale bot to tackle our growing backlog of stale issues. Once it started closing issues, the community feedback was quick to arrive. The biggest complaint was that issues were closed automatically as stale, without a human from the engineering team ever weighing in. So we walked the automation back, step by step. First, we changed the stale bot to no longer close issues, only mark them stale and leave them open for the team to review. Then we reviewed all open issues carrying that label. With the backlog under control, we removed the stale bot for issues altogether. Later, we even re-triaged the closed stale issues that had at least one vote. Most turned out to be duplicates or already fixed. Today, no automation can silently close an issue. What's more, we don't miss any comments under closed issues: if somebody comments on a closed issue, it will be re-triaged. There are still around a thousand issues in our main repository closed by the stale bot. We don't plan to re-triage them, assuming they are obsolete. If the stale bot closed an issue you still care about, just leave a comment and we'll take another l

## Essential Tips for Gradle on Ephemeral CI Environments - Part 3

DevFeed: [Essential Tips for Gradle on Ephemeral CI Environments - Part 3](<https://devfeed.tech/articles/essential-tips-for-gradle-on-ephemeral-ci-environments-part-3-24633.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-on-ephemeral-ci-3>)

Author: Louis Jacomet

Published: 2026-07-09T04:00:00Z

Content type: tutorial

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Spring Boot](<https://devfeed.tech/topics/spring-boot.md>)

Tags: [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [build](<https://devfeed.tech/tags/build.md>), [cache](<https://devfeed.tech/tags/cache.md>), [docker](<https://devfeed.tech/tags/docker.md>), [docker-image](<https://devfeed.tech/tags/docker-image.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [performance](<https://devfeed.tech/tags/performance.md>), [spring-boot](<https://devfeed.tech/tags/spring-boot.md>)

### AI overview

This tutorial explains how to optimize Gradle's Execution phase in ephemeral CI environments, focusing on the Gradle Build Cache and task-output reuse. It describes benchmarking a small Spring Boot project in a Docker environment and cautions that the measurements are approximate and specific to Gradle 9.5.1 and the stated test setup.

### Source excerpt

In Part 1 and Part 2, we optimized Gradle's Startup and Configuration phases on ephemeral CI. In this final part, we reach the Execution phase: the point where Gradle checks whether task outputs can be reused and, when they cannot, runs the selected tasks. This is where the Gradle Build Cache becomes the main lever. Benchmarking Performance in Ephemeral CI The methodology is unchanged from Part 1 and Part 2: each scenario builds a fresh Docker image of the Spring Boot Project with --no-cache, base images are pre-pulled, and every figure is the average of ten runs against one consistent baseline. Individual runs vary by a second or two, so read small differences as approximate rather than exact. These numbers are not intended as universal Gradle performance claims. They show the relative impact of execution-phase optimizations for one small Spring Boot project, one Gradle version, one JDK image, and one local Docker environment. Larger builds, especially multi-module builds with expensive compilation, testing, code generation, or packaging tasks, will generally see bigger gains from task-output reuse than this sample project does. NOTE: All measurements in this post are pinned to Gradle 9.5.1. If you repeat the experiment with a newer Gradle version, rebuild the prime image and update any version-specific cache paths accordingly. The baseline (no optimizations) averaged 32.3s over ten runs, in line with the ~31.5s baselines from Parts 1 and 2. Optimizations for the Execution Phase During the Execution phase, Gradle runs the task graph that was selected and ordered during configuration. For each task, Gradle decides whether work can be avoided before it executes task actions: Input and output snapshotting: Gradle fingerprints the task's declared inputs, outputs, and relevant implementation details. Reuse checks: Gradle determines whether the task is already up to date locally, or whether matching outputs can be loaded from the Build Cache. Task action execution: Gradl

## Essential Tips for Gradle on Ephemeral CI Environments - Part 2

DevFeed: [Essential Tips for Gradle on Ephemeral CI Environments - Part 2](<https://devfeed.tech/articles/essential-tips-for-gradle-on-ephemeral-ci-environments-part-2-24632.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-on-ephemeral-ci-2>)

Author: Louis Jacomet

Published: 2026-07-08T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Spring Boot](<https://devfeed.tech/topics/spring-boot.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [build-performance](<https://devfeed.tech/tags/build-performance.md>), [cache](<https://devfeed.tech/tags/cache.md>), [docker](<https://devfeed.tech/tags/docker.md>), [github](<https://devfeed.tech/tags/github.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [jdk](<https://devfeed.tech/tags/jdk.md>), [spring-boot](<https://devfeed.tech/tags/spring-boot.md>)

### AI overview

Part 2 examines Gradle configuration-phase performance in ephemeral CI environments, focusing on dependency and script caching and the roles of the setup-gradle GitHub Action and Develocity Universal Cache.

### Source excerpt

In Part 1, we explored foundational strategies for improving Gradle build performance in ephemeral CI environments, focusing on the Startup and Initialization phase. Now, in Part 2, we shift our focus to the Configuration phase: the work Gradle does after startup but before it executes any tasks. We'll benchmark dependency and script caching, then look at where the setup-gradle GitHub Action and Develocity's Universal Cache fit. Benchmarking Performance in Ephemeral CI The methodology is the same as in Part 1: each scenario builds a fresh Docker image of the Spring Boot Project with --no-cache, base images are pre-pulled, and every figure is the average of ten runs against one consistent baseline. Individual runs vary by a second or two, so read small differences as approximate rather than exact. These numbers are not intended as universal Gradle performance claims. They show the relative impact of configuration-phase optimizations for one small Spring Boot project, one Gradle version, one JDK image, and one local Docker environment. Larger builds, with more dependencies and more build logic, will generally see bigger gains from dependency and script caching than a small sample project does. NOTE: All measurements in this post are pinned to Gradle 9.5.1. If you repeat the experiment with a newer Gradle version, rebuild the prime image and update any version-specific cache paths accordingly. One difference from Part 1: for the Configuration phase, we prime the cache by building the complete Spring Boot Project, not the empty Prime Project. Caching configuration-phase work only means something when there are real dependencies and real build scripts to cache, so the prime image must reflect a realistic project. As in Part 1, that prime image is built once and only restored from, so the timed builds measure cache restore, not cache creation. Building the full project populates the following directories in the Gradle User Home: .gradle/ <-- Gradle User Home (default: ~/.

## Essential Tips for Gradle on Ephemeral CI Environments - Part 1

DevFeed: [Essential Tips for Gradle on Ephemeral CI Environments - Part 1](<https://devfeed.tech/articles/essential-tips-for-gradle-on-ephemeral-ci-environments-part-1-24631.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-on-ephemeral-ci-1>)

Author: Louis Jacomet

Published: 2026-07-07T04:00:00Z

Content type: tutorial

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [GitHub Actions](<https://devfeed.tech/topics/github-actions.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Spring Boot](<https://devfeed.tech/topics/spring-boot.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [caching](<https://devfeed.tech/tags/caching.md>), [ci](<https://devfeed.tech/tags/ci.md>), [docker](<https://devfeed.tech/tags/docker.md>), [efficiency](<https://devfeed.tech/tags/efficiency.md>), [github](<https://devfeed.tech/tags/github.md>), [github-actions](<https://devfeed.tech/tags/github-actions.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

This article explains how to optimize Gradle builds in ephemeral CI environments, where short-lived containers and cloud-based build agents eliminate persistent state. It compares common Gradle optimizations, discusses caching and workflow adaptations, and describes benchmarking on a small Spring Boot project in a Docker-based environment.

### Source excerpt

Ephemeral CI replaces long-lived, stateful build agents with short-lived, disposable environments, typically powered by containers and cloud services like GitHub Actions or Docker, to ensure isolated, reliable, and repeatable builds. While this approach improves consistency, security, and scalability, it also eliminates persistent state, requiring new strategies for caching and setup efficiency. This post covers practical strategies to overcome those limitations and keep Gradle fast. With the right optimizations, Gradle's flexibility and tooling support ephemeral workflows well. Common Gradle Optimizations While numerous Gradle optimizations are widely recommended and beneficial in traditional CI, their effectiveness in ephemeral CI environments varies significantly. Many common optimizations rely on persistence and statefulness, making them less effective or more complex to maintain in ephemeral contexts. Here's a closer look at how these popular Gradle optimizations perform in ephemeral CI: # Optimization for Local or Traditional CI Builds Effective in Ephemeral CI? Reason 1 Enable the Build Cache ✅ Highly effective when remote caching is leveraged; local caching alone has limited utility 2 Tailor workflows (task avoidance) ✅ Helpful but requires careful planning and continuous adjustments 3 Increase Gradle's heap size ✅ Immediate benefits without significant setup overhead 4 Enable parallel execution ✅ Efficiently uses cloud resources 5 Optimize the configuration phase (lazy APIs, applying plugins selectively, etc.) ✅ Effective but requires rigorous management of configuration logic 6 Optimize dependency resolution (declarative syntax, remove dynamic versions, etc.) ✅ Helpful, though gains are often marginal in ephemeral CI 7 Re-use the Dependency Cache 🔷 Manual reuse is fiddly; the free setup-gradle action provides it on GitHub Actions, and Develocity's Artifact Cache provides it on any CI 8 Enable the Configuration Cache ✅ Increasingly enabled by default in mod

## gradle/actions in GitHub Actions Workflows

DevFeed: [gradle/actions in GitHub Actions Workflows](<https://devfeed.tech/articles/you-are-probably-already-running-gradle-actions-24690.md>)

Original publisher: [Read original article](<https://blog.gradle.org/running-gradle-github-actions>)

Author: Laura Kassovic

Published: 2026-06-30T04:00:00Z

Content type: opinion

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [GitHub Actions](<https://devfeed.tech/topics/github-actions.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [Caching](<https://devfeed.tech/topics/caching.md>)

Tags: [caching](<https://devfeed.tech/tags/caching.md>), [github](<https://devfeed.tech/tags/github.md>), [github-actions](<https://devfeed.tech/tags/github-actions.md>), [gradle](<https://devfeed.tech/tags/gradle.md>)

### AI overview

An opinionated primer on gradle/actions, especially setup-gradle, which helps Gradle run in ephemeral GitHub Actions runners. It discusses the action's adoption and the importance of caching Gradle state in CI.

### Source excerpt

There is a particular kind of software that you depend on heavily and have never once thought about. It does not have a landing page you have visited. It was not chosen at an architecture review. Nobody sat in a conference room and debated it against three competitors, and no one wrote a blog post titled "Why We Migrated To It." It simply showed up one day, did its job, and has been doing its job on every commit since. A great deal of the build automation running on GitHub is this kind of software. And one of the most widely used examples, if you write anything that touches the Java Virtual Machine, is a small collection of GitHub Actions published by Gradle at gradle/actions. You may not recognize the name setup-gradle. But it's used by more than 45,000 open source repositories, and it's the action baked into GitHub's own official starter workflow for Gradle projects. When you click "Set up a workflow" on a fresh Gradle repo and accept the suggestion GitHub hands you, you are adopting gradle/actions without ever having formed an opinion about it. This is how the most consequential defaults always spread: not by persuasion but by presumption. It is the same mechanism by which much of Europe enrolls organ donors. So: a primer on what the thing does, a tour of who actually runs it in production, and an argument about why the unglamorous parts are the ones worth caring about. What it actually is gradle/actions is not one action. It is a small family of them, and in practice, almost everyone means the same one when they invoke it. The centerpiece is setup-gradle. Its job is to make Gradle run well inside a GitHub Actions runner, which is a fresh, ephemeral machine that has never heard of your project and will be deleted the moment your build finishes. Left to its own devices, that machine re-downloads your dependencies, re-initializes Gradle, and re-does a pile of work it has no memory of having done five minutes ago on the previous commit. setup-gradle is what gives th

## The Four Kotlin Versions in a Gradle Project

DevFeed: [The Four Kotlin Versions in a Gradle Project](<https://devfeed.tech/articles/the-four-kotlin-versions-in-a-gradle-project-24698.md>)

Original publisher: [Read original article](<https://blog.gradle.org/three-kotlin-versions-in-a-gradle-project>)

Author: Laura Kassovic

Published: 2026-06-12T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [gradle-plugin](<https://devfeed.tech/tags/gradle-plugin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-compiler](<https://devfeed.tech/tags/kotlin-compiler.md>), [syntax](<https://devfeed.tech/tags/syntax.md>)

### AI overview

This article explains the four Kotlin versions that can matter in a Gradle project: the Kotlin compiler version selected through the Kotlin Gradle Plugin, the language version targeted for project code, the Kotlin compiler bundled with Gradle for build logic, and the language version Gradle pins for that build logic.

### Source excerpt

Do you know what version of Kotlin your Gradle build is using? There are four Kotlin versions you need to know about in a project built with Gradle. They're easy to mix up, and mixing them up can lead to some confusion (and the occasional compiler error). The trick is that there are really only two compilers in play, and each one carries its own language-version dial. Two compilers, two dials, four numbers. Let's take them one at a time. This post was updated on June 16, 2026. 1. The Kotlin that compiles your code This is the version most people look for. If your application or library code is written in Kotlin and gets compiled by the Kotlin Gradle Plugin, you pick its version in your build: // build.gradle.kts plugins { kotlin("jvm") version "1.9.25" } Change the KGP version, and you change the Kotlin compiler used to compile your project. This is the version you control directly. 2. The Kotlin language version for your code Picking the KGP version chooses which compiler runs over your code. But that compiler has a second dial: the language version, which decides what Kotlin syntax it will accept. You set it through KGP: // build.gradle.kts kotlin { compilerOptions { languageVersion = KotlinVersion.KOTLIN_1_8 } } By default it matches the language version associated with your KGP version, so most projects never touch it. You can pin it lower, for example to keep a library compilable by projects still on an older Kotlin. #1 is the compiler; this is the language level you ask that compiler to target. 3. The Kotlin embedded in Gradle (that compiles your build logic) Now the other compiler. Gradle ships its own Kotlin compiler and standard library inside the distribution. It's the compiler that builds your Kotlin DSL scripts and Gradle-managed build logic, and its standard library is available on the classpath used by build scripts and plugins. You never declare this one. It comes bundled with whatever Gradle version you use. In Gradle 9.6.0: # gradle/wrapper/gradle-w

## How AWS Powers Gradle's Open Source Build Tool

DevFeed: [How AWS Powers Gradle's Open Source Build Tool](<https://devfeed.tech/articles/how-aws-powers-gradle-s-open-source-build-tool-24641.md>)

Original publisher: [Read original article](<https://blog.gradle.org/how-aws-powers-gradle-open-source>)

Author: Bo Zhang

Published: 2026-06-09T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Security](<https://devfeed.tech/topics/security.md>), [AWS IAM](<https://devfeed.tech/topics/aws-iam.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>), [Amazon Elastic Kubernetes Service](<https://devfeed.tech/topics/amazon-elastic-kubernetes-service.md>), [Amazon S3](<https://devfeed.tech/topics/amazon-s3.md>), [OpenID connect (OIDC)](<https://devfeed.tech/topics/oidc.md>)

Tags: [amazon-ec2](<https://devfeed.tech/tags/amazon-ec2.md>), [amazon-eks](<https://devfeed.tech/tags/amazon-eks.md>), [amazon-rds](<https://devfeed.tech/tags/amazon-rds.md>), [aws](<https://devfeed.tech/tags/aws.md>), [aws-identity-and-access-management-iam](<https://devfeed.tech/tags/aws-identity-and-access-management-iam.md>), [ci](<https://devfeed.tech/tags/ci.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [oidc](<https://devfeed.tech/tags/oidc.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [security](<https://devfeed.tech/tags/security.md>), [testing](<https://devfeed.tech/tags/testing.md>)

### AI overview

The article explains how AWS supports Gradle's open source build tool, including plugin distribution through Amazon S3, large-scale builds and tests on Amazon EC2 and Amazon EKS, performance tracking with Amazon RDS, and layered security and observability services.

### Source excerpt

The Gradle Build Tool runs a lot of the world's software. Millions of developers use it every day, and almost every Android app on your phone was built with it. So somebody, somewhere, is kicking off a Gradle build right now. And the next one. And a thousand more in the next minute. For all of them, it has to be fast, and it has to be there. That isn't free. Behind the open source project sits a plugin portal serving hundreds of millions of downloads a month, a CI fleet running millions of tests, a performance lab watching for regressions, and the security tooling that guards a supply chain a lot of the industry depends on. All of it runs on AWS. Here's how. Downloading plugins The Gradle Plugin Portal at plugins.gradle.org is where the community publishes the plugins that extend Gradle. Every plugin JAR it serves (thousands of them, downloaded around 200 million times a month) lives in Amazon S3. That's what lets us be the front door for the plugin ecosystem without running a fleet of file servers ourselves. Building and testing Gradle itself Most of our AWS bill goes here. Every commit to Gradle triggers hundreds of separate builds and tens of thousands of tests across our supported operating systems and architectures. That fleet runs on: Amazon EC2, with auto-scaling to match capacity to demand. Amazon EKS, which orchestrates our containerized Test Distribution agents. Amazon ECR, which stores the agent container images. Keeping Gradle fast A build tool only earns trust if it stays fast. Every commit runs through our performance test suite, and the results land in Amazon RDS, where we compare against history and catch regressions before they reach users. Securing the build Protecting a build tool means protecting a supply chain. Our CI authenticates to AWS through AWS Identity and Access Management (IAM) with GitHub OIDC. That gives us keyless, short-lived credentials, and any secrets we still need are pulled on demand from AWS Secrets Manager and AWS Systems Man

## The (Petty) Reason We Didn't End Up Using jj

DevFeed: [The (Petty) Reason We Didn't End Up Using jj](<https://devfeed.tech/articles/the-petty-reason-we-didn-t-end-up-using-jj-24697.md>)

Original publisher: [Read original article](<https://blog.gradle.org/the-petty-reason-we-didnt-end-up-using-jj-at-gradle>)

Author: Laura Kassovic

Published: 2026-06-02T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Windows](<https://devfeed.tech/topics/windows.md>), [Batch file](<https://devfeed.tech/topics/batch-file.md>)

Tags: [batch](<https://devfeed.tech/tags/batch.md>), [git](<https://devfeed.tech/tags/git.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [version-control](<https://devfeed.tech/tags/version-control.md>), [windows](<https://devfeed.tech/tags/windows.md>)

### AI overview

The article explains why Gradle did not adopt Jujutsu (jj) as a replacement for Git in a developer's workflow. The blocker is Jujutsu's lack of support for the per-file line-ending rules in .gitattributes, which causes persistent phantom modifications to gradlew.bat in Gradle repositories.

### Source excerpt

Jujutsu (jj) has been picking up steam as a Git-compatible version control system. When used with its Git backend, jj stores commits and files in Git and works with existing Git repositories, but it does away with the staging area so your working copy is represented as a real commit that updates as you go. Rewriting history is cheap and safe: edit or reorder a commit and jj rebases its descendants for you; conflicts can be recorded instead of halting the operation; and operations can be undone from the operation log. Recently, one of our engineers set out to replace git with jj in their day-to-day flow. Unfortunately, it didn't work out. Not because of anything fundamental about jj's model, but because of a small detail of how Gradle projects are shaped on disk. This is worth writing down, because we suspect a lot of teams in the JVM ecosystem will hit the same wall. The actual blocker: gradlew.bat and .gitattributes A typical Gradle repository ships the Gradle Wrapper, which usually includes gradlew.bat. That script uses labels and goto, which cmd.exe can mishandle when a batch file has LF-only line endings, so gradlew.bat has to be checked out with CRLF to run reliably on Windows. We enforce this with .gitattributes, a file that tells Git how to handle specific files or paths, controlling things like line-ending normalization and whether files are treated as binary or text: *.bat text eol=crlf This is standard Git behavior: the file is stored normalized in the index, and the eol=crlf attribute tells Git to materialize CRLF in the working copy on checkout. Edits are normalized back on the way in. You forget about it after the first commit. jj doesn't read .gitattributes, so it can't apply a per-file rule. There's a long-standing issue (jj-vcs/jj#53) tracking support for at least the eol attribute, but until it lands jj's only lever is the global working-copy.eol-conversion setting. That's the rough equivalent of Git's core.autocrlf: it applies to every file at once

## How Gradle Is Javamaxxing

DevFeed: [How Gradle Is Javamaxxing](<https://devfeed.tech/articles/how-gradle-is-javamaxxing-24628.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-is-javamaxxing>)

Author: Laura Kassovic

Published: 2026-05-28T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Java](<https://devfeed.tech/topics/java.md>), [toolchains](<https://devfeed.tech/topics/toolchains.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>)

Tags: [bytecode](<https://devfeed.tech/tags/bytecode.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [garbage-collectors](<https://devfeed.tech/tags/garbage-collectors.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [java](<https://devfeed.tech/tags/java.md>), [java-8](<https://devfeed.tech/tags/java-8.md>), [jdk](<https://devfeed.tech/tags/jdk.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [openjdk](<https://devfeed.tech/tags/openjdk.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance-optimization](<https://devfeed.tech/tags/performance-optimization.md>), [release](<https://devfeed.tech/tags/release.md>)

### AI overview

Gradle aggressively adopts new JDK releases because newer JVMs can improve build speed, memory use, startup behavior, and maintainability. JVM toolchains allow Gradle to run on JDK 26 while compiling and testing projects for older Java versions, including producing Java 8-compatible bytecode.

### Source excerpt

Some people optimize one part of their lives to the absolute limit, then past it. They call it "-maxxing." Houseplantmaxxing. Sleepmaxxing. Tokenmaxxing. The Gradle Build Tool is Javamaxxing. TL;DR Breathe easy knowing you can run modern Gradle on JDK 26 while still shipping Java 8-compatible artifacts: Gradle aggressively adopts new JDKs because newer JVMs make builds faster, leaner, and easier to maintain. Upgrading the JDK that runs Gradle is often the easiest performance win. JVM toolchains fully separate the JVM running Gradle, the JVM compiling your code, and the JVM running your tests. NOT TL;DR We aggressively adopt new JDK releases as soon as we responsibly can. Not because it's trendy. Because newer JDKs make Gradle faster, leaner, and easier to maintain. Every OpenJDK release ships improvements to the JVM; garbage collectors, compiler infrastructure, startup behavior, memory layout, and runtime APIs. As a high-performance JVM build tool, Gradle benefits directly from all of it. The question people immediately ask is: Does this mean my project also has to run on the newest JDK? No. That coupling effectively disappeared once Gradle introduced JVM toolchains. With toolchains, the JVM that runs Gradle is completely separate from the JVM that compiles, tests, and executes your code. You can run Gradle on JDK 26 today and still produce Java 8 bytecode. What Is the Current State of Gradle and Java? We add daemon support for every new JDK as soon as the ecosystem permits: Java 24 in Gradle 8.14.0, Java 25 in 9.1.0 (released two days after JDK 25 GA), Java 26 in 9.4.0. The full mapping is in the Compatibility Matrix. We then bump the minimum JVM required to execute Gradle as users move. Gradle 9.0.0, released on July 31, 2025, raised the minimum JVM required to run the Gradle daemon to Java 17. That was the first daemon JVM floor increase since Gradle 5.0 made Java 8 the minimum back in 2018. The next major transition is already underway, Gradle 10.0.0 will likely

## Achieving Fast Inner Dev Loops with Gradle: Configuration Cache and Beyond

DevFeed: [Achieving Fast Inner Dev Loops with Gradle: Configuration Cache and Beyond](<https://devfeed.tech/articles/achieving-fast-inner-dev-loops-with-gradle-configuration-cache-and-beyond-24617.md>)

Original publisher: [Read original article](<https://blog.gradle.org/fast-inner-dev-loops-with-gradle>)

Author: Alex Semin

Published: 2026-05-20T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [code productivity](<https://devfeed.tech/topics/code-productivity.md>), [build performance](<https://devfeed.tech/topics/build-performance.md>), [build times](<https://devfeed.tech/topics/build-times.md>), [Development](<https://devfeed.tech/topics/development.md>)

Tags: [build](<https://devfeed.tech/tags/build.md>), [build-tool](<https://devfeed.tech/tags/build-tool.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [context](<https://devfeed.tech/tags/context.md>), [developer-productivity](<https://devfeed.tech/tags/developer-productivity.md>), [flow](<https://devfeed.tech/tags/flow.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [incremental](<https://devfeed.tech/tags/incremental.md>), [kotlinconf](<https://devfeed.tech/tags/kotlinconf.md>), [parallelism](<https://devfeed.tech/tags/parallelism.md>), [productivity](<https://devfeed.tech/tags/productivity.md>)

### AI overview

This article explains how Gradle is working to accelerate inner developer loops. It describes the shift from execution time to configuration time as the main build bottleneck in large codebases, while highlighting configuration cache, incremental builds, build cache, and parallelism as approaches to reduce waiting and preserve developer flow.

### Source excerpt

How many engineers in your organization have to sit idle for 10 or more minutes just to rebuild the app locally after a small change? If you're an engineering leader, build engineer, or part of a developer productivity team, you're not alone in facing this challenge. Building complex software is inherently demanding, but the time your developers spend waiting has a profound impact beyond just the literal minutes lost. It fundamentally disrupts their psychological flow. "There are like these time scales of psychological flow, right? So if something takes longer than a minute, you already start planning for it... you suffer from context switch as well. If it's 1 second, that's where we want to be right in that seamless state of flow. And if it's less than one second, then you feel it's like magic... productive developers are happy developers." -- Rodrigo Oliveira When developers have to wait, their attention drifts, and the cost of context switching destroys their momentum. Our goal as enablers of developer productivity should be to eliminate this friction, bringing that feedback loop as close as possible to the "magical one second". In a recent presentation at KotlinConf 2025, Gradle engineers Rodrigo Oliveira and Alex Semin detailed how Gradle Build Tool is evolving to keep developers in that productive, happy "flow state". By tackling the most significant bottlenecks in modern software builds, Gradle is paving the way for incredibly fast inner developer loops. If you prefer to watch the presentation recording, you can find it here. The shifting bottleneck: From execution to configuration On every invocation, Gradle goes through three distinct phases: initialization, configuration, and execution. Historically, when we optimized Gradle builds, we focused almost exclusively on the execution phase. This is when the majority of work expected by a developer happens: production sources compilation, test execution, etc. For years, execution was the longest phase. We tackled thi

## Choice, Clarity, and the Future of Caching in Gradle Actions

DevFeed: [Choice, Clarity, and the Future of Caching in Gradle Actions](<https://devfeed.tech/articles/choice-clarity-and-the-future-of-caching-in-gradle-actions-24602.md>)

Original publisher: [Read original article](<https://blog.gradle.org/choice-clarity-future-caching-gradle-actions>)

Author: Daz DeBoer

Published: 2026-04-03T04:00:00Z

Content type: release

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [caching](<https://devfeed.tech/tags/caching.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [github](<https://devfeed.tech/tags/github.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [release](<https://devfeed.tech/tags/release.md>)

### AI overview

Gradle Actions 6.1.0 responds to licensing concerns by clarifying that Gradle claims no ownership of cached content and by introducing a Basic Caching provider. The new provider is fully open source, uses path-based caching backed by GitHub, and offers an alternative to the proprietary Enhanced Caching option.

### Source excerpt

Since the release of gradle/actions v6, we've been listening closely to the feedback from the community. It's clear that while we were focused on building the next generation of caching for Gradle, we missed the mark on how we communicated the changes to licensing that came with the release. As the maintainer of this project, my goal is to ensure this action remains a tool the community trusts. Today, we are releasing version 6.1.0, which puts transparency and user choice at the forefront. 1. Data Ownership: The "Safe Harbor" Clause The most significant concern we heard was that our new license terms were overly broad, leading some to fear that Gradle might claim ownership of the cached data processed by the action. Let me be clear: Your code and artifacts belong to you. Period. To formalize this, we have updated the Gradle Technologies Terms of Use to include a Safe Harbor clause specifically for cached content. This clause explicitly confirms that Gradle claims no ownership of the content of your cache entries. We may collect metadata (such as cache keys) and usage metrics to facilitate and improve the caching service, but the actual cached data will not be inspected or retained. For more details on licensing of gradle/actions and gradle-actions-caching, please see our new Distribution & Licensing Guide. 2. Restoring Choice: The "Basic" Caching Provider In v6.0, we introduced Enhanced Caching via the proprietary gradle-actions-caching component as the only caching option with setup-gradle. We understand that for some, having a 100% open-source path is a requirement, not a preference. In v6.1, we are introducing a Basic Caching provider. This is a 100% open-source thin wrapper over actions/cache. It provides reliable, path-based caching backed by GitHub. You now have a choice. If you prefer to stay entirely within the MIT-licensed ecosystem, you can opt out of the proprietary library with one line of configuration: - uses: gradle/actions/setup-gradle@v6 with: cache

## GitHub Actions for Gradle v6: What's Changing and Why

DevFeed: [GitHub Actions for Gradle v6: What's Changing and Why](<https://devfeed.tech/articles/github-actions-for-gradle-v6-what-s-changing-and-why-24620.md>)

Original publisher: [Read original article](<https://blog.gradle.org/github-actions-for-gradle-v6>)

Author: Gradle Build Tool

Published: 2026-03-24T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [GitHub Actions](<https://devfeed.tech/topics/github-actions.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [blog-post](<https://devfeed.tech/tags/blog-post.md>), [cache](<https://devfeed.tech/tags/cache.md>), [caching](<https://devfeed.tech/tags/caching.md>), [ci](<https://devfeed.tech/tags/ci.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [github-actions](<https://devfeed.tech/tags/github-actions.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [open-source](<https://devfeed.tech/tags/open-source.md>)

### AI overview

This article announces v6 of GitHub Actions for Gradle builds. The Gradle User Home caching functionality has been extracted from setup-gradle into the closed-source gradle-actions-caching library, while the rest of the action remains open source and workflows continue to function without new functional restrictions. v6 also removes experimental Configuration Cache support, which is being reworked for broader project compatibility.

### Source excerpt

UPDATE: We published a follow-up to this post -- Choice, Clarity, and the Future of Caching in Gradle Actions Today, we're releasing v6 of GitHub Actions for Gradle builds, with an important change to how the caching component is licensed. In this blog post, we explain what's changing, what it means for you, and where we're headed. GitHub Actions for Gradle builds is a collection of GitHub Actions that makes it easy to configure and run Gradle builds on GitHub Actions CI. The centerpiece is setup-gradle, which provides a convenient way to invoke Gradle in GitHub Actions workflows with sophisticated, efficient caching across invocations, GitHub Dependency Graph support, automatic capture of Build Scan® links, and more. It's used by over 45,000 open source repositories and is featured in GitHub's official starter workflows. Since its introduction, GitHub Actions for Gradle builds, including the caching implementation in setup-gradle, have been fully open source under the MIT license. That changes with v6. What's changing Starting with v6, the functionality of setup-gradle that saves and restores Gradle User Home state has been extracted to gradle-actions-caching, a closed-source library distributed under our Terms of Use. The rest of the action remains open source. While the caching functionality of setup-gradle is now under a proprietary license, we are not introducing any functional restrictions in this release. Your workflows will continue to function as before. The only functional change in v6 is the removal of the experimental Configuration Cache support. It was not production-ready and worked only for a limited set of projects. We're reworking this feature so that it works for most projects and more users can benefit (more on this below). To upgrade, simply update your workflow files to reference v6: - uses: gradle/actions/setup-gradle@v6 By upgrading to v6, you accept the Terms of Use for the gradle-actions-caching component. Why we're making this change Support

## Avoiding the Next Supply Chain Disaster with GitHub and Gradle

DevFeed: [Avoiding the Next Supply Chain Disaster with GitHub and Gradle](<https://devfeed.tech/articles/avoiding-the-next-supply-chain-disaster-with-github-and-gradle-24596.md>)

Original publisher: [Read original article](<https://blog.gradle.org/avoid-supply-chain-disaster-with-github-gradle>)

Author: Tom Tresansky

Published: 2026-02-25T05:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [supply-chain-security](<https://devfeed.tech/topics/supply-chain-security.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [Vulnerabilities](<https://devfeed.tech/topics/vulnerabilities.md>), [Reverse Dependencies](<https://devfeed.tech/topics/reverse-dependencies.md>), [Java](<https://devfeed.tech/topics/java.md>), [Android](<https://devfeed.tech/topics/android.md>), [Maven](<https://devfeed.tech/topics/maven.md>), [npm](<https://devfeed.tech/topics/npm.md>), [Logging](<https://devfeed.tech/topics/logging.md>)

Tags: [dependencies](<https://devfeed.tech/tags/dependencies.md>), [developers](<https://devfeed.tech/tags/developers.md>), [github](<https://devfeed.tech/tags/github.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [java](<https://devfeed.tech/tags/java.md>), [locking](<https://devfeed.tech/tags/locking.md>), [logging](<https://devfeed.tech/tags/logging.md>), [npm](<https://devfeed.tech/tags/npm.md>), [security](<https://devfeed.tech/tags/security.md>), [supply-chain](<https://devfeed.tech/tags/supply-chain.md>), [supply-chain-attacks](<https://devfeed.tech/tags/supply-chain-attacks.md>), [supply-chain-security](<https://devfeed.tech/tags/supply-chain-security.md>), [vulnerabilities](<https://devfeed.tech/tags/vulnerabilities.md>)

### AI overview

This article explains how GitHub and Gradle can help Android and JVM developers reduce software supply-chain risk. It covers dependency drift, vulnerability exposure, resolved dependency visibility, continuous monitoring, automated fixes, and Build Scan® analysis, with Shai-Hulud and Log4Shell as examples of supply-chain threats.

### Source excerpt

Supply chain security is a big deal, and it's dangerously easy to ignore. For Android or JVM developers, the sheer scale of the ecosystem is our greatest strength, and our greatest risk. When you build an application, you aren't just responsible for your own code; you're responsible for a massive, invisible tree of dependencies. This presents two distinct security challenges: Dependency Drift: Resolved dependencies can appear, disappear, or change versions without you ever touching your build.gradle.(kts) file. A bad actor can slip a malicious artifact into your dependency graph unnoticed. Vulnerability Exposure: Even locking your dependencies to avoid unexpected changes doesn't absolve you from monitoring their state. A library you've used for years might have a critical vulnerability (CVE) discovered tomorrow. We've recently seen this play out in the wild with attacks like the Shai-Hulud npm supply-chain exploit, where attackers poisoned popular packages to execute arbitrary code downstream, and the critical Log4Shell vulnerability, which demonstrated the catastrophic risk posed by an exploit in a foundational Java logging library. We recently outlined our defense against supply chain attacks in our deep dives on continuous GRC and our Nx vulnerability response. The good news: if your Gradle projects live on GitHub, you already have everything you need to minimize your known vulnerability count, without manually auditing resolved dependencies all day. In this post, we'll walk through how GitHub and Gradle work together to: Give you a complete, accurate view of your resolved dependencies Continuously monitor those dependencies for vulnerabilities Automatically propose and validate fixes Use our free Build Scan® service to understand what changed and why Why dependency monitoring is harder than it looks Unlike more traditional build tools like Maven, which rely on relatively static dependency declarations, Gradle is a dynamic, highly programmable build engine. While

## Detecting Maven-Hijack-style risks in Gradle builds with the Dependency Analysis Gradle Plugin

DevFeed: [Detecting Maven-Hijack-style risks in Gradle builds with the Dependency Analysis Gradle Plugin](<https://devfeed.tech/articles/detecting-maven-hijack-style-risks-in-gradle-builds-with-the-dependency-analysis-gradle-plugin-24611.md>)

Original publisher: [Read original article](<https://blog.gradle.org/detect-maven-hijack-risks-in-gradle-with-plugin>)

Author: Laura Kassovic

Published: 2025-12-08T05:00:00Z

Content type: tutorial

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [supply-chain-security](<https://devfeed.tech/topics/supply-chain-security.md>), [software supply-chain attack](<https://devfeed.tech/topics/software-supply-chain-attack.md>), [Java](<https://devfeed.tech/topics/java.md>), [Vulnerabilities](<https://devfeed.tech/topics/vulnerabilities.md>)

Tags: [dependency](<https://devfeed.tech/tags/dependency.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [gradle-plugin](<https://devfeed.tech/tags/gradle-plugin.md>), [java](<https://devfeed.tech/tags/java.md>), [software-supply-chain](<https://devfeed.tech/tags/software-supply-chain.md>), [software-supply-chain-attack](<https://devfeed.tech/tags/software-supply-chain-attack.md>), [supply-chain-security](<https://devfeed.tech/tags/supply-chain-security.md>), [vulnerabilities](<https://devfeed.tech/tags/vulnerabilities.md>)

### AI overview

This tutorial explains how Maven-Hijack-style attacks exploit duplicate fully qualified class names, deterministic Maven packaging order, and JVM classloader behavior in Java builds. It presents DAGP 3.5.0, the Dependency Analysis Gradle Plugin, as a defense that warns about duplicate classes and checks binary compatibility to identify potentially ambiguous bytecode.

### Source excerpt

JVM builds have lived with "duplicate classes on the classpath" for years. Most of the time, it's an annoying source of NoSuchMethodError or a "why did production suddenly break when I reordered dependencies?" kind of bug. A recent academic paper, Maven-Hijack: Software Supply Chain Attack Exploiting Packaging Order, shows that this isn't just a reliability problem, it's also a supply-chain security problem. DAGP 3.5.0 (Dependency Analysis Gradle Plugin), a popular community plugin, now provides another line of defense: in addition to warning you about duplicate classes, it checks binary compatibility when it finds them. That means it can spot cases where "the same class name" actually refers to different bytecode, which is exactly the kind of ambiguity Maven-Hijack exploits. We'll explore how to use DAGP to protect against Maven-Hijack style attacks in Gradle builds. If you've heard about supply chain vulnerabilities in the npm / Nx ecosystem, we've also written about how Continuous GRC can help block compromised packages across your org. What Maven-Hijack actually does The Maven-Hijack paper describes a class of attacks that rely on two facts about the Java ecosystem: Maven packaging order is deterministic - When building an uber-JAR, Maven walks the dependency tree in depth-first order and packages classes in that order. Dependencies earlier in that traversal "win" when there are duplicates. The JVM classloader loads the first matching class on the classpath - At runtime, the Java classloader linearly scans the classpath and loads the first class whose fully-qualified name matches the one being requested. That's enough to build an attack: The attacker finds a gadget dependency, a library that contains a class they'd love to hijack (e.g., a JDBC driver or some other central integration point). They then compromise or control an infection dependency that appears earlier in the dependency tree and publish a new version that contains a class with the same fully quali

## Gradle Now Maintains the Official Docker Image

DevFeed: [Gradle Now Maintains the Official Docker Image](<https://devfeed.tech/articles/gradle-now-maintains-the-official-docker-image-24613.md>)

Original publisher: [Read original article](<https://blog.gradle.org/docker-image-ownership>)

Author: Laura Kassovic

Published: 2025-09-15T04:00:00Z

Content type: release

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Docker Image](<https://devfeed.tech/topics/docker-image.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Docker Hub](<https://devfeed.tech/topics/docker-hub.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [GitHub Actions](<https://devfeed.tech/topics/github-actions.md>), [GitLab](<https://devfeed.tech/topics/gitlab.md>), [Jenkins](<https://devfeed.tech/topics/jenkins.md>)

Tags: [ci-cd](<https://devfeed.tech/tags/ci-cd.md>), [docker](<https://devfeed.tech/tags/docker.md>), [docker-hub](<https://devfeed.tech/tags/docker-hub.md>), [docker-image](<https://devfeed.tech/tags/docker-image.md>), [github](<https://devfeed.tech/tags/github.md>), [github-actions](<https://devfeed.tech/tags/github-actions.md>), [gitlab](<https://devfeed.tech/tags/gitlab.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [jenkins](<https://devfeed.tech/tags/jenkins.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [releases](<https://devfeed.tech/tags/releases.md>), [support](<https://devfeed.tech/tags/support.md>)

### AI overview

Gradle is now the official maintainer of the Gradle Docker image on Docker Hub. The article explains that the image will be kept current with Gradle releases, including security updates, while its usage, CI workflows, and community support continue to evolve.

### Source excerpt

We're excited to announce we're now the official maintainer of the Gradle image on Docker Hub. For years, developers have relied on the Gradle Docker image to run builds in containers and CI/CD pipelines. Originally created and maintained by community contributor Keegan Witt, this image became a trusted resource for thousands of teams. Today, we're bringing it under the Gradle organization to ensure it remains reliable, up to date, and aligned with Gradle's release cadence. Why this Matters Docker is a critical part of modern software delivery. Many teams build and test their projects in containerized environments, and CI/CD platforms like GitHub Actions, GitLab CI, and Jenkins depend on official images to provide consistency and trust. By becoming the official maintainer of the Gradle Docker image, we can: Provide timely updates for each Gradle release, including security fixes Ensure alignment with the official Gradle -bin distributions Collaborate with the community to evolve the image for new use cases Provide support through the standard support channels (Slack and Community Forum) This also reduces the burden on individual contributors who've generously kept the image running until now. A big Thank You We want to recognize Keegan Witt, who has maintained the Gradle Docker image for years. His diligent work ensured developers could trust the image long before it became officially supported. We're grateful for his contributions and stewardship! What to Expect Going Forward The official Gradle Docker image will continue to be published under hub.docker.com/_/gradle. Images will be kept aligned with Gradle releases to the greatest extent possible. We'll review and evolve best practices for image usage, including improvements for CI workflows and ephemeral build environments. Using the Image Try the latest official image today: docker pull gradle:latest Or specify a versioned tag: docker pull gradle:9.0.0-jdk17 Get Involved The Gradle Docker image remains open sour

[Next page](<https://devfeed.tech/sources/the-gradle-blog.md?cursor=WyIyMDI1LTA5LTE1VDA0OjAwOjAwKzAwOjAwIiwgIjIxMDA3ZGQyLTNiYTgtNGZlNy04ZWM4LWI3OWZjZDJmYThlNCJd>)