# Gradle Published articles for Gradle. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Java News Roundup: New OpenJDK JEPs, CDI 5.0, Spring, Open Liberty, RefactorFirst, ADK for Kotlin DevFeed: [Java News Roundup: New OpenJDK JEPs, CDI 5.0, Spring, Open Liberty, RefactorFirst, ADK for Kotlin]() Original publisher: [Read original article]() Author: Michael Redlich Published: 2026-09-14T20:15:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Java](), [Concurrency](), [JDK 27](), [releases](), [Jakarta EE](), [Gradle](), [Groovy]() Tags: [2026](), [architecture-design](), [concurrency](), [development](), [gradle](), [groovy](), [jakarta-ee](), [java](), [java-news-roundup-sep07-2026](), [jdk-27](), [jdk-28](), [kotlin](), [micronaut](), [news](), [open-jdk](), [open-liberty](), [refactorfirst](), [releases](), [spring-framework](), [tornadovm]() ### AI overview A Java news roundup for September 7, 2026, covers new OpenJDK proposals for ahead-of-time compilation and structured concurrency, Jakarta CDI 5.0 and ADK for Kotlin 1.0, Open Liberty, TornadoVM, RefactorFirst, Micronaut, Groovy 6.0, and Gradle 9.8. It also reports current JDK 27 and JDK 28 early-access builds and describes improvements in TornadoVM 6.1.0. ### Source excerpt This week's Java roundup for September 7th, 2026, features news highlighting: new JEPs for ahead-of-time compilation and structured concurrency; GA releases of Jakarta CDI 5.0 and ADK for Kotlin 1.0; the September 2026 edition of Open Liberty; point releases of TornadoVM and RefactorFirst; a maintenance release of Micronaut; and first releases candidates of Groovy 6.0 and Gradle 9.8. By Michael Redlich ## Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork DevFeed: [Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork]() Original publisher: [Read original article]() Author: Sajid Ali Published: 2026-09-14T04:24:43Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [compose-multiplatform](), [tvOS](), [Kotlin Multiplatform](), [Gradle]() Tags: [apple](), [build](), [compiler](), [compose-multiplatform](), [gradle](), [gradle-plugin](), [ios](), [jetbrains](), [multiplatform](), [source]() ### AI overview This tutorial explains the build setup for adding tvOS support to a Compose Multiplatform fork. It covers Kotlin Multiplatform targets, source-set organization shared between iOS and tvOS, and the build-layer work used to identify missing modules and dependencies. ### Source excerpt Compose Multiplatform on tvOS This series: Compose Multiplatform on tvOS My Journey Making Compose Multiplatform Work on tvOS, and What I Learned Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork (this post) Rendering (coming soon) Siri Remote input (coming soon) Siri Remote trackpad (coming soon) Screen density and text input (coming soon) Porting tv-material (coming soon) The Gradle plugin and third-party libraries (coming soon) Maintaining the fork (coming soon) Building a real app on it (coming soon) Part 1 was why this fork exists. This one is the build layer, and it comes before any Compose code, because in Kotlin Multiplatform a target is not a flag you flip at the end. It decides which source sets compile, which dependencies resolve, which klibs get published, which linker flags get passed. Until the build knows about tvosArm64, nothing tells you what is missing. So the first commits were build files. Once the targets were on, the compiler listed what was missing, module by module, and I worked through that list. Source set layout on the tvos branch I started on a branch called tvos, based on upstream. Back then JetBrains called iOS "uikit" in this repository and the source set was uikitMain. Because tvOS is also UIKit underneath, it made sense to have a common source parent for both iOS and tvOS. But iOS was already being called uikit, so I chose uiKitCommonMain as the source set name and moved all the UIKit files there, keeping only the iOS specific files in uikitMain and putting the tvOS specific files in a new source set, tvosMain. The problem with this approach was how to keep up with upstream. I tried a symlink to the uikit source set, and then overriding the tvOS files in a separate target. The override worked but complicated the process. At that time my goal was to make it runnable on tvOS however possible, so we would have a proof of concept. So I did a lot of hacks in the tvos branch to make it runnable, and af ## Koin Compiler 1.2: Compile-Time Safety for ALL Koin DSL DevFeed: [Koin Compiler 1.2: Compile-Time Safety for ALL Koin DSL]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-09-10T12:01:01Z Content type: release Language: en Sources: [Koin developers - Medium]() Topics: [Compiler](), [Kotlin](), [Gradle]() Tags: [compiler](), [dependencies](), [dependency-injection](), [gradle](), [implementation](), [koin](), [kotlin](), [kotlin-multiplatform]() ### AI overview Koin Compiler Plugin 1.2, with 1.2.1 as the latest patch, extends compile-time validation to Koin's reified, constructor, and classic lambda DSLs. It also adds visibility across Gradle modules, supports additional entry points, and provides one artifact for Kotlin 2.3.20 through 2.4.20 without requiring a DSL migration. ### Source excerpt Hello, dear Koin community 👋 I'm happy to share that Koin Compiler Plugin 1.2 is out, with 1.2.1 already available as the latest patch. Developer mascott unboxing new Koin Features!TL;DR Compile-time validation now works on the Koin application you already have, where before 1.2 it only covered code written specifically for the compiler plugin. Koin DSL -- All now covered! All Koin DSL: the plugin's reified DSL, Koin's constructor DSL (singleOf(::T)), and the classic lambda DSL (single { Foo(get()) }). Across Gradle modules: definitions are now visible two or more implementation hops away. More entry points: Ktor's install(Koin) and KoinApplication.withConfiguration(). One artifact for Kotlin 2.3.20 through 2.4.20. You get there with no migration to a new DSL, and nothing to rewrite. Let's go through what shipped. Covering now all Koin DSL Until now, compile-time safety only covered the plugin's own reified DSL, which means the two DSL styles you have most likely already written were invisible to it. val appModule = module { single() // checked singleOf(::UserRepository) // not checked before 1.2 single { AnalyticsHelper(get()) } // not checked before 1.2 } Three ways to declare a definition, and only the first was validated. If your UserRepository needed a Database that no module provided, your build passed and Koin threw at runtime. In 1.2, all three are validated. The two DSL styles get there differently. For the constructor DSL, the referenced constructor's parameters become real requirements, exactly like single(), and any named() qualifier you put on the registration is matched against the consumers that ask for it. The classic lambda DSL works differently. The plugin doesn't try to work out dependencies from free-form lambda code. What it validates instead are the get() calls you wrote inside the lambda, treated as ordinary resolution call sites. Before 1.2 those calls were skipped on purpose, because a hand-written get() is difficult to dis ## 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]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-09-09T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Testing](), [ai-coding](), [Benchmark](), [Fable](), [Documentation](), [bug]() Tags: [ai-coding](), [benchmark](), [bug](), [docs](), [fable](), [gradle](), [testing]() ### 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 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 ## A Multi-Module Android Template with Kotlin Convention Plugins, Lint Rules, and Design System Tokens DevFeed: [A Multi-Module Android Template with Kotlin Convention Plugins, Lint Rules, and Design System Tokens]() Original publisher: [Read original article]() Author: Shamil Gulmetov Published: 2026-09-09T01:34:18Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [Template](), [Android](), [Architecture & Design](), [Kotlin](), [Gradle](), [Jetpack Compose](), [Dependency injection](), [Automation](), [Refactoring](), [now-in-android]() Tags: [android](), [android-app-development](), [android-architecture](), [android-studio](), [architecture](), [automation](), [best-practices](), [build](), [compose](), [dependency-injection](), [gradle](), [how-to](), [jetpack-compose](), [kotlin](), [now-in-android](), [refactoring]() ### AI overview This tutorial presents an Android Architecture Template based on patterns from Google's Now in Android repository. It describes a multi-module structure with Gradle Version Catalogs, Kotlin Convention Plugins, Jetpack Compose design tokens and dark-theme support, dependency injection, custom Lint rules, and a terminal-based renaming tool. ### Source excerpt How to streamline your development workflow with pre-configured Kotlin Convention Plugins, custom Lint rules, and unified design system tokens. Creating a new Android application from scratch in modern engineering is rarely as simple as clicking File -> New -> New Project in Android Studio. Before writing a single line of business logic, developers face hours -- or even days -- of repetitive infrastructure setup: Configuring a scalable multi-module architecture. Setting up Gradle Version Catalogs and writing custom Kotlin Convention Plugins to eliminate build script duplication. Standardizing design tokens and dark theme support in Jetpack Compose. Wiring up Hilt Dependency Injection for Coroutine Dispatchers, network, and Application Scopes. Enforcing architectural boundaries and team coding standards using custom static analysis (Lint) rules. Google's official Now in Android (NiA) repository is the recognized gold standard for modern Android engineering. However, because NiA is a full-featured showcase app with domain logic (news feeds, authors, bookmarks, offline sync), using it as a starter kit is cumbersome: developers must strip out existing features while risking breaking build pipelines. This Android Architecture Template bridges that gap: a clean, production-ready starter kit that extracts NiA's best architectural patterns into an isolated foundation. To make it enterprise-ready with zero room for error, it includes a standalone automation tool. Instead of manual refactoring, run a single terminal command to rename and brand the entire architecture in seconds. Acknowledgments & Credits Core architectural decisions, build-logic convention plugins, and static analysis infrastructure in this template are directly inspired by Google's official Now in Android (NiA) repository. Rather than reinventing the wheel, this template focuses on developer ergonomics--making Google's best practices instantly usable out of the box. 1. Modular Project Architecture The repository ## Kotlin 2.4.20 Released DevFeed: [Kotlin 2.4.20 Released]() Original publisher: [Read original article]() Author: Daniel Csorba Published: 2026-09-07T11:30:57Z Content type: release Language: en Sources: [Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog](), [The JetBrains Blog]() Topics: [releases](), [Command-line interface](), [Android Studio](), [IntelliJ IDEA]() Tags: [android-studio](), [command-line](), [features](), [github](), [gradle](), [intellij](), [issue-tracker](), [kotlin](), [release](), [releases](), [swift](), [testing](), [wasm](), [youtrack]() ### AI overview Kotlin 2.4.20 adds standard-library, compiler, build-tool, Kotlin/Native, Kotlin/Wasm, and Kotlin/JS updates. The article also explains how to update Kotlin in supported IDEs or obtain the command-line compiler. ### Source excerpt The Kotlin 2.4.20 release is out! Here are the main highlights: For the complete list of changes, see What's new in Kotlin 2.4.20 or the release notes on GitHub. How to install Kotlin 2.4.20 The latest version of Kotlin is included in the latest versions of IntelliJ IDEA and Android Studio. To update to the [...] ## Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More DevFeed: [Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More]() Original publisher: [Read original article]() Author: Joffrey Bion Published: 2026-09-03T10:40:05Z Content type: release Language: en Sources: [Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog]() Topics: [toolchain](), [multiplatform](), [compose-hot-reload](), [web applications](), [Spring Boot 4]() Tags: [compose-hot-reload](), [gradle](), [intellij-idea](), [kotlin](), [multiplatform](), [news](), [publication](), [releases](), [toolchain](), [toolchains](), [wasm]() ### AI overview Kotlin Toolchain 0.12.0 adds multiplatform library publishing and previews support for building Wasm modules as web applications. It also includes command-line Compose Hot Reload and changes intended to reduce Maven Central publication files. ### Source excerpt Kotlin Toolchain 0.12.0 is out. This release brings some long-awaited features: multiplatform libraries publication, a preview of Wasm application support, Compose Hot Reload from the command line, and more. Read on for the details, and check the release notes for the full list of changes and bug fixes. Additionally, klibs.io now uses the Kotlin Toolchain [...] ## Introducing the Gradle Security Subscription DevFeed: [Introducing the Gradle Security Subscription]() Original publisher: [Read original article]() Author: Gradle Build Tool Published: 2026-08-31T04:00:00Z Content type: release Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Security](), [toolchain](), [Vulnerabilities]() Tags: [gradle](), [open-source](), [releases](), [security](), [toolchain](), [vulnerabilities]() ### 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 ## Add sign-in to an Android app with the WorkOS Android SDK DevFeed: [Add sign-in to an Android app with the WorkOS Android SDK]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-24T00:00:00Z Content type: tutorial Language: en Sources: [WorkOS Blog]() Topics: [Android](), [SDKs](), [Kotlin](), [Authentication](), [pkce](), [Gradle](), [Coroutines](), [API keys](), [Security](), [Maven Central](), [Mobile]() Tags: [android](), [api](), [api-keys](), [authentication](), [coroutines](), [flow](), [gradle](), [kotlin](), [maven-central](), [pkce](), [sdk](), [security](), [sign-in](), [tutorial]() ### AI overview This tutorial shows how to add WorkOS AuthKit sign-in to a Kotlin Android app using the WorkOS Android SDK. It covers the Gradle dependency, Chrome Custom Tab authentication, custom-scheme redirects, PKCE token exchange, session storage and refresh, and logout without embedding a client secret in the APK. ### Source excerpt Build a complete AuthKit flow in Kotlin, from Gradle dependency to signed-out state, with no client secret in your APK. ## Java Weekly, Issue 660 DevFeed: [Java Weekly, Issue 660]() Original publisher: [Read original article]() Author: baeldung Published: 2026-08-22T11:26:18Z Content type: article Language: en Sources: [Baeldung]() Topics: [API](), [JSON](), [Quarkus](), [Gradle](), [Retrieval Augmented Generation (RAG)](), [Amazon Bedrock](), [agent observability]() Tags: [amazon-bedrock](), [api](), [gradle](), [java](), [json](), [no-ads](), [no-after-post](), [no-before-post](), [no-optins](), [rag](), [release](), [weekly-review](), [weekly-review-no-ads-no-after-post-no-before-post-no-optins]() ### AI overview Java Weekly, Issue 660 is a roundup of Java ecosystem news, including a Hibernate second-level cache performance case study, a proposed small JSON API for JDK 28, Gradle and Renovate integration, AI and RAG resources, and recent Quarkus and other library releases. ### Source excerpt A clear Hibernate speedup and a new JSON API coming to Java. The post Java Weekly, Issue 660 first appeared on Baeldung. ## Gradle Is Going Agentic DevFeed: [Gradle Is Going Agentic]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-08-19T04:00:00Z Content type: opinion Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Tooling](), [benchmarking](), [configuration](), [Cache]() Tags: [agentic](), [benchmarking](), [cache](), [configuration](), [context-window](), [gradle](), [tooling]() ### 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 ## Jetpack XR SDK core libraries reach beta: The next milestone for Android XR DevFeed: [Jetpack XR SDK core libraries reach beta: The next milestone for Android XR]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-18T17:00:00Z Content type: release Language: en Sources: [Android Developers Blog](), [Android Developers Blog]() Topics: [SDKs](), [releases]() Tags: [3d](), [android-xr](), [beta-announcement](), [compose](), [gradle](), [jetpack](), [jetpack-xr-sdk](), [release](), [testing]() ### AI overview Jetpack SceneCore, ARCore for Jetpack XR, and XR Runtime have reached beta. The article describes their roles in building immersive and augmented Android XR apps and directs developers to add the latest XR libraries to Gradle projects. ### Source excerpt Posted by Amy Zeppenfeld, Developer Relations Engineer, Greg Underwood, Software Engineering Manager, Yasmine Evjen, Senior Product Manager, Android XR Since introducing the Android XR SDK, developers have transformed their ideas into innovative, immersive experiences for XR headsets and wired XR glasses. As the ecosystem expands, you can more easily take those experiences from preview to production and reach users wherever they are. Today, we're excited to announce that Jetpack SceneCore, ARCore for Jetpack XR, and XR Runtime have reached beta with Jetpack Compose for XR to follow soon! This means the APIs are stabilizing, making it a great time to start integrating them into your production workflows and creating for Android XR. Why the Jetpack XR SDK? The Jetpack XR SDK includes all the tools and libraries you need to build immersive and augmented experiences for Android XR. Whether you're porting an existing 2D app or creating a new 3D XR app from scratch, you can do so using the familiar Android development tools you already know and love. To support your development, this release focuses on providing the fundamental building blocks across the SDK: Jetpack SceneCore: Build and manipulate the Android XR scene graph with 3D content. You can arrange 3D models, play spatial audio, and use the robust entity-component system to create, control, and manage entities. ARCore for Jetpack XR: Bring digital content into the real world with perception capabilities. This library powers depth estimation, persistent anchors, hit testing, and plane identification. XR Runtime: Provides the essential runtime foundation of the SDK, handling device lifecycles, session creation, and system configurations that enable the API surface. Jetpack Compose for XR: Create spatial UI layouts that take advantage of Android XR's spatial capabilities. This library lets you use familiar Compose concepts to create spatial UIs and will be reaching Beta soon. What's new in Beta? Direct feedback from ## Solving Gradle metadata and Renovate integration DevFeed: [Solving Gradle metadata and Renovate integration]() Original publisher: [Read original article]() Author: Nicolas Fränkel Published: 2026-08-16T00:00:00Z Content type: tutorial Language: en Sources: [Nicolas Fränkel]() Topics: [Gradle](), [renovate](), [Kotlin](), [Groovy]() Tags: [ci](), [dependencies](), [dependency](), [development](), [gradle](), [renovate](), [software-supply-chain](), [supply-chain-attacks](), [supply-chain-security]() ### AI overview The article describes setting up Renovate for a Gradle project and investigating why merges of updated dependency versions caused build failures. It also discusses dependency verification and software supply chain risks. ### Source excerpt My current company has settled on using Gradle. It doesn't make me very happy, but you need to learn to work with constraints. Plus, I must admit that the developers who actually implemented the build files did a pretty good job overall: they used Kotlin instead of Groovy, they moved code to regular plugins, etc. This week, I worked on improvements to a new project and set up Renovate. ## Java Weekly, Issue 659 DevFeed: [Java Weekly, Issue 659]() Original publisher: [Read original article]() Author: baeldung Published: 2026-08-15T10:23:09Z Content type: article Language: en Sources: [Baeldung]() Topics: [Programming](), [intellij-platform](), [Model Context Protocol](), [elasticsearch]() Tags: [elasticsearch](), [github](), [gradle](), [idea](), [java](), [mcp](), [netflix](), [no-ads](), [no-after-post](), [no-before-post](), [no-optins](), [programming](), [releases](), [security](), [weekly-review](), [weekly-review-no-ads-no-after-post-no-before-post-no-optins]() ### AI overview Java Weekly, Issue 659 is a roundup of Java ecosystem reading, including MCP server evolution, Project Valhalla, JVM security, DuckDB, HTTP extension design, AI features in IntelliJ IDEA, webinars, and software releases. ### Source excerpt Equality in Java is evolving. The post Java Weekly, Issue 659 first appeared on Baeldung. ## 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]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-08-13T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [IntelliJ IDEA](), [ide](), [2026.2](), [configuration]() Tags: [2026-2](), [autocomplete](), [build](), [feature](), [gradle](), [ide](), [intellij-idea](), [kotlin](), [upgrade]() ### 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]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-08-11T04:00:00Z Content type: opinion Language: en Sources: [The Gradle Blog]() Topics: [ci](), [pull-requests](), [Gradle](), [configuration](), [Caching]() Tags: [cache](), [ci](), [configuration](), [gradle](), [pull-request]() ### 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]() Original publisher: [Read original article]() Author: Alex Semin Published: 2026-08-06T04:00:00Z Content type: release Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Optimization](), [configuration](), [releases](), [Command-line interface]() Tags: [configuration](), [feature](), [gradle](), [make](), [optimization](), [releases]() ### 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)]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-07-28T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Kotlin](), [Groovy](), [ide](), [Scripting](), [Refactoring]() Tags: [2026](), [best-practices](), [build](), [build-tool](), [conference](), [developer](), [dsl](), [event](), [gradle](), [groovy](), [ide](), [kotlin](), [kotlinconf](), [refactoring](), [script](), [scripting](), [talk](), [talks]() ### 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]() Original publisher: [Read original article]() Author: Alex Semin Published: 2026-07-22T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Scalability](), [Cache](), [configuration](), [Dependency management](), [ci](), [ide]() Tags: [cache](), [ci](), [configuration](), [dependency-management](), [gradle](), [ide](), [parallelism](), [performance]() ### 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 ## Bring your KMP library to NuGet DevFeed: [Bring your KMP library to NuGet]() Original publisher: [Read original article]() Author: Isuru Rajapakse Published: 2026-07-19T13:17:14Z Content type: tutorial Language: en Sources: [Stories by Isuru Rajapakse on Medium]() Topics: [Kotlin Multiplatform](), [NuGet](), [Kotlin](), [C#](), [.NET](), [Gradle](), [multiplatform](), [Library](), [API]() Tags: [android](), [android-app-development](), [androiddev](), [c-sharp](), [gradle](), [interfaces](), [kmp](), [kotlin](), [kotlin-multiplatform](), [library](), [multiplatform](), [net](), [nuget](), [nuget-package]() ### AI overview The article introduces kotlin-native-nuget, a Gradle plugin that packages Kotlin/Native libraries as NuGet packages with generated idiomatic C# bindings. It explains the motivation, configuration, publishing workflow, and supported mappings for Kotlin features such as classes, enums, data classes, coroutines, generics, interfaces, and exceptions. ### Source excerpt with kotlin-native-nuget plugin, you can bring your Kotlin to C# idiomaticallyhttps://medium.com/media/0f185efc67390bbf440bfc33f5675f42/href A little while ago, I gave a talk where I tried to take a library written in Kotlin and hand it to a .NET developer as a NuGet package. By hand. It is 30 minutes of me walking into every brick wall you can imagine - the C ABI, marshalling strings, keeping objects alive across the boundary, making any of it look like C# a human would actually want to use. Introducing kotlin-native-nuget 🪟kotlin-native-nuget plugin auto-binds your kotlin api into C# I turned all of that into a plugin, so you don't have to hit a single one of those walls. You write Kotlin, and out the other side comes a NuGet package with a proper, idiomatic C# API: classes, enums, data classes, coroutines, Flow, generics, interfaces, the works. No FFI boilerplate, no hand-written [DllImport], no "here's a C header, good luck". Your friends over in .NET just `dotnet add package` it and use it like it was C# all along. It's called kotlin-native-nuget, and it's a Gradle plugin. Here's the pitch: GitHub - xxfast/kotlin-native-nuget: A plugin that packages a Kotlin/Native library as a NuGet package with generated C# bindings, and consumes C# NuGet packages from Kotlin The pitch 🛗plugins { kotlin("multiplatform") id("io.github.xxfast.kotlin.native.nuget") version "" } kotlin { mingwX64 { binaries { sharedLib { baseName = "mycatlib" } } } macosArm64 { binaries { sharedLib { baseName = "mycatlib" } } } } nuget { publish { packageId = "MyCatLib" version = "1.0.0" authors = "yourname" description = "My Kotlin/Native library" rootPackage = "com.example.cats" } } That's it. Add the plugin, point it at your native targets, and run the publish task. Out pops a .nupkg. Why though? 🤔 It's a fair question. I got it a lot (even on that talk) Kotlin Multiplatform already reaches an absurd number of places: the JVM, Android, iOS, JS, Wasm, and native desktop. But there's th ## Rewriting Claw's HTML parser for over-the-air updates DevFeed: [Rewriting Claw's HTML parser for over-the-air updates]() Original publisher: [Read original article]() Author: Harsh Shandilya Published: 2026-07-17T13:34:00Z Content type: opinion Language: en Sources: [Posts on Harsh Shandilya]() Topics: [HTML](), [Android](), [API](), [CSS](), [Rails](), [JavaScript](), [Gradle]() Tags: [android](), [api](), [css](), [debugging](), [firefox](), [gradle](), [html](), [javascript](), [kotlin-multiplatform](), [llms]() ### AI overview The article describes rewriting the HTML parser in the Android app Claw, which browses Lobsters, after concerns about relying on the site's unsupported JSON API. It explains the parsing work, the breakage caused by markup changes, and the search for faster over-the-air deployment using approaches such as Expo EAS Update and Cash App's Zipline. ### Source excerpt Struggling through a brand new framework so I can hotfix my app faster ## Gradle Technologies Renames Itself Develocity DevFeed: [Gradle Technologies Renames Itself Develocity]() Original publisher: [Read original article]() Author: Gradle Build Tool Published: 2026-07-17T04:00:00Z Content type: news Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Open Source](), [observability]() Tags: [announcement](), [company](), [gradle](), [open-source]() ### 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 ## Android Studio Quail 4 Canary 1 now available DevFeed: [Android Studio Quail 4 Canary 1 now available]() Original publisher: [Read original article]() Author: Android Studio Releaser (noreply@blogger.com) Published: 2026-07-16T13:28:23Z Content type: release Language: en Sources: [Android Studio Release Updates]() Topics: [Android Studio](), [Android Gradle Plugin](), [Gradle](), [Emulator](), [Linux](), [macOS]() Tags: [android](), [android-gradle-plugin](), [android-studio](), [emulator](), [gradle](), [linux](), [macos](), [preview](), [release](), [release-notes]() ### AI overview Android Studio Quail 4 Canary 1 is available in the Canary channel. The release includes general fixes and changes involving Android Studio, Android Gradle Plugin, Gradle integration, lint, navigation, and emulator-related behavior. ### Source excerpt Android Studio Quail 4 Canary 1 is now available in the Canary channel. If you already have an Android Studio build on the Canary channel, you can get the update by clicking Help > Check for Updates (or Android Studio > Check for Updates on macOS). Otherwise, you can download it here. For information on new features and changes in Android Studio Quail 4, see the Android Studio Preview release notes. General fixes and features Below is a list of general fixes in Android Studio Quail 4 Canary 1 and Android Gradle Plugin 9.4.0-alpha05. These are a result of your bug reports, which help us to make Android Studio better. If you encounter a problem, let us know by reporting a bug. You can also vote for an existing issue to indicate that it also affects you. Fixed Issues Android Studio Issue #533146818 ExtractAnnotations task does not share build cache entries between mac and linux Gradle Integration Issue #491718901 AGP 9.1.0 Circular dependency error between :app:l8DexDesugarLibUiTest and :app:minifyAndroidTestWithR8 Lint Issue #526716181 Disable DalvikOverride by default Issue #533527424 Lint tasks do not share build cache entries between mac and linux Navigation Editor Issue #271424916 nested navigation graph as starting destination breaks Android Studio Preview Running Devices Issue #532163938 "Hardware Input" emulator option is not persisted across Android Studio restarts ## 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]() Original publisher: [Read original article]() Author: Vlad Chesnokov Published: 2026-07-16T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [issue tracker](), [GitHub](), [Automation](), [pull-requests]() Tags: [automation](), [bug](), [documentation](), [github](), [gradle](), [issue-tracker](), [pull-requests](), [usability]() ### 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 [Next page]()