Groovy 6.0 RC1: Async/Await and Virtual Threads Are Here

Apache Groovy 6.0 RC1 dropped last week, and most developers missed it. While Java 27 and .NET 11 RC1 grabbed September’s headlines, Groovy quietly shipped what its community has asked for since 2018: native async/await backed by virtual threads. The JDK floor moves to 17. The XML security story is completely rewritten. If you run Gradle build scripts, Jenkins Pipelines, or Spock test suites, this release touches your stack whether you notice it or not.

JDK 17 Is the New Floor — Check Your CI First

Groovy 6 drops support for everything below JDK 17. Groovy 5 ran on JDK 8 and above; Groovy 6 is tested on JDK 17 through 27. That is a bigger jump than it sounds. If your Jenkins agents, CI Docker images, or build pipelines are still pinned to JDK 11 — and many are, especially in enterprise environments — you cannot upgrade to Groovy 6 without bumping the JVM first.

The good news: JDK 17 is the most widely deployed LTS release as of 2026 and has been for over a year. If you have been putting off the JDK upgrade, Groovy 6 is the forcing function. JDK 21 users get an additional payoff, which leads directly to the headline feature.

Native Async/Await Lands — With Virtual Threads on JDK 21+

Groovy 6 adds async {} blocks and await() as first-class language features. On JDK 21 and above, tasks inside an async block automatically run on virtual threads — no configuration, no thread pool sizing, no executor boilerplate. On JDK 17–20, a cached thread pool handles the work as a fallback.

The result is concurrency you can actually read:

def a = async { fetchFromServiceA() }
def b = async { fetchFromServiceB() }
def (resultA, resultB) = await(a, b)

That replaces callback chains and CompletableFuture.allOf() boilerplate that nobody enjoys writing. The design avoids the “function coloring” problem: the caller decides what runs concurrently, not the method signature. A normal Groovy closure becomes async when wrapped in async {}. Existing methods do not need the suspend annotation that Kotlin coroutines require.

For structured concurrency, AsyncScope.withScope {} guarantees that all sub-tasks are cancelled and cleaned up when the scope exits — no orphaned virtual threads leaking into the next request:

AsyncScope.withScope { scope ->
    def user   = scope.async { fetchUser(id) }
    def orders = scope.async { fetchOrders(id) }
    [user: await(user), orders: await(orders)]
}

This is conceptually identical to Java 27’s StructuredTaskScope from JEP 533 — except Java has been previewing structured concurrency for four release cycles and it is still not stable. Groovy ships it as a production-ready API in RC1.

Generators and Go-Style Channels

The groovy.concurrent package consolidates the full concurrency toolkit — async/await, generators, Go-style channels, actors, dataflow variables, and parallel collections — behind a single import. An async closure containing yield return becomes a lazy generator that produces values on demand. AsyncChannel supports filter, map, merge, split, and tap operations, with ChannelSelect for multi-channel coordination.

The standalone groovy-concurrent-java module makes all of this available to Java and Kotlin callers as well. Teams that are not ready to write Groovy can still pull in the channel and async primitives from Java code — a quiet but meaningful detail for mixed-language JVM shops.

XML Security Is Now a Non-Event

Groovy has had an XXE problem for a long time. Parsing untrusted XML in Groovy scripts — Jenkins Pipelines consuming webhook payloads, for example — required explicitly hardening the XMLInputFactory or risking XML external entity injection. Most scripts did not bother. In Groovy 6, the hardened factory is the default. Both streaming and DOM-based XML APIs are protected out of the box. No opt-in flag, no documentation to read. This is the correct way to ship a security fix.

How to Try RC1 and What to Avoid

Install the release candidate via Snap:

snap install --channel 6.x/candidate groovy-lang

Or download directly from the official Groovy download page. RC1 ships 51 fixes and improvements. The full feature breakdown is in the Groovy 6.0 release notes.

One critical caveat: do not migrate Gradle .groovy build scripts yet. Gradle’s tested Groovy version for the Groovy DSL is 4.x, and Groovy 6 compatibility with Gradle plugins is unconfirmed. Hold on build.gradle migration until the Gradle team publishes guidance. The async and concurrency features are best evaluated in Spock test suites and standalone Groovy scripts first.

GA timing has not been announced, but RC1 proceeding without major blockers suggests a late 2026 stable release is realistic. The InfoQ Java roundup for September 7 flagged the RC as notable for the async/await story alone. Every major JVM language is converging on “write sequential, run concurrent.” Groovy 6 arrives at the right time — even if it is a few years behind Kotlin on the async feature clock.