Release notes for Groovy 6.0

Without async/await, concurrent code requires chaining futures:

With async/await, the same logic reads like synchronous code:

Exception handling works with standard try/catch — no .exceptionally() chains.

Launch tasks concurrently and coordinate results:

An async closure containing yield return becomes a lazy generator — it produces values on demand with natural back-pressure:

Go-style inter-task communication. A producer sends values into a channel (AsyncChannel); a consumer receives them:

AsyncScope binds the lifetime of child tasks to a scope — when the scope exits, all children are guaranteed complete or cancelled:

for await consumes an async source — a generator, channel, or reactive stream — pulling values as they arrive, while defer registers a cleanup action that runs when the enclosing scope exits (LIFO order, on success or failure alike):

defer is a contextual keyword: it is parsed as a keyword only inside async closures, so existing code that uses defer as an ordinary identifier elsewhere is unaffected (GROOVY-12254).

See the Async/Await user guide for the full API and additional examples.

An Agent wraps a value and serialises updates via functions, eliminating data races by design. Reads compose with await:

An agent also exposes its update stream as a java.util.concurrent.Flow.Publisher via changes(), so for await consumes state transitions directly:

A hand-written actor (Actor) encodes its message protocol explicitly — typed messages, a switch over message kinds, and send/sendAndGet plumbing at every call site — so a reader (human or AI) has to trace each message kind through the dispatch loop and every call site to know the actor is used safely. @ActiveObject (target: TYPE) inverts this: write a normal class, mark the methods that run on the actor’s serialised mailbox with @ActiveMethod (target: METHOD), and the AST transform routes those calls through an internal actor:

The thread-safety contract is now explicit and local. The @ActiveObject annotation declares the concurrency model; @ActiveMethod bodies contain plain business logic; callers see ordinary method calls — no message types to invent, no switch to parse, no manual reply plumbing. For non-blocking use, @ActiveMethod(blocking = false) returns an Awaitable that plugs straight into await and Awaitable.all.

A DataflowVariable is a single-assignment variable: any thread that reads before it is bound blocks until a value is available. DataflowVariable implements Awaitable, so it composes directly with await and async {} regardless of which task binds first:

The companion Dataflows class auto-creates variables on property access for an even more concise form (async { df.fullName = "${df.first} ${df.last}" }).

For CPU-bound data parallelism, Collection gains a family of parallel methods backed by a ForkJoinPool:

ParallelScope.withPool binds a pool for a block, and Pool offers Pool.cpu(), Pool.fixed(n), Pool.io(), and Pool.virtual() factories so CPU-bound and I/O-bound workloads can use distinct pools without leaking into the common pool. The previously introduced @Parallel loop annotation shares this infrastructure:

As a rule of thumb, prefer parallel collections (or @Parallel) for CPU-bound work and async/await with virtual threads for I/O-bound work — ForkJoinPool workers are precious and should not be tied up in Thread.sleep, network calls, or blocking I/O.

AsyncChannel (introduced with async/await) gains composable pipeline operations — filter, map, merge, split, tap — and ChannelSelect for Go-style multi-channel selection. BroadcastChannel adds one-to-many delivery and exposes asPublisher() for direct Flow.Publisher interop, so any subscriber — including a for await loop — receives every message:

The same for await works against any JDK Flow.Publisher, Reactor Flux (via groovy-reactor), or RxJava Observable (via groovy-rxjava).

ChannelSelect.from(a, b, …​) waits for the first available value from several channels, as Go’s select does. In Groovy 6 it grew from that starting point into the full choice construct of the CSP literature, and the underlying protocol changed to make that sound: a select now works by claim — the branches share one flag that a channel tests under its own lock immediately before handing a value over, so exactly one branch dequeues and the losing branches never touch their channels (GROOVY-12320).

Four capabilities build on that:

Choice policy. A ready channel completes during registration, so select() takes the channel listed first — a priority select, under which a channel that always has a value waiting starves those after it. fair() rotates the registration order so every ready channel is taken within n calls (JCSP’s fairSelect), and random() shuffles it so every ready channel is equally likely (Go’s policy). Keep the instance across calls for fair() to rotate.

Mixed offers. A branch may offer to send as well as receive — "I will send my opener, or take my peer’s if it sends first" (GROOVY-12323):

Exactly one offer commits; a committed send behaves exactly like ping.send(1), while a retired one leaves no trace — no buffered residue, no waiting sender.

Preconditions. when writes a guard onto the offer itself, as occam, Ada, Erlang and Kotlin do — the guarded choice of CSP (GROOVY-12326):

A guarded-off offer is not registered on its channel but keeps its position, so result.index denotes the same branch either way — dropping the offer from the argument list instead would silently renumber every branch after it. The guard is a closure, consulted afresh on each select() call, so one select can be built once and reused as the state it guards on changes. The same preconditions can be passed positionally, one flag per offer, which suits a mask computed as a whole (GROOVY-12324); a flag conjoins with whatever guard its offer carries.

Timeouts as a branch. A deadline can be a branch of the select rather than an exception thrown around it by orTimeout (GROOVY-12343). The timer offer after re-arms on every round; the timer channel AsyncChannel.after is a fixed deadline shared by every round that selects on it:

A timer offer that loses its round is cancelled with the other losing branches, so it leaves nothing armed. Listed last, after(0) has already elapsed and so is ready at registration — making it the default clause of Go’s select: take a transfer if one can complete at once, otherwise proceed without waiting.

See the Async/Await user guide for the full select API, including result.channel for recognising a branch by identity rather than position.

For Java, Kotlin, and other JVM languages that want the same toolkit without the full Groovy runtime, the standalone groovy-concurrent-java module exposes AsyncScope, Pool, ParallelScope, Actor, Agent, DataflowVariable, AsyncChannel, BroadcastChannel, and ChannelSelect against plain java.util.function types. The Groovy-only sugar (async/await keywords, for await, defer, @ActiveObject, Dataflows, parallel extension methods) requires the full Groovy dependency.

The module ships under the org.apache.groovy:groovy-concurrent-java coordinate and is mutually exclusive with the full groovy runtime (Gradle enforces this via a shared capability; a runtime warning fires if both jars are detected on the classpath).

See the user guides for the full APIs and additional examples: concurrent actors and agents, concurrent dataflow, parallel collections, and the Java-only module.

A closure-based DSL for quick scripting:

Responses auto-parse by content type: result.json, result.xml, result.html (via jsoup), or result.parsed for auto-dispatch.

Define a typed interface and Groovy generates the implementation at compile time. Parameters are mapped by convention — no annotations needed for the common case:

Both sides offer native async via HttpClient.sendAsync() — no extra threads consumed while waiting:

These CompletableFuture returns are first-class await targets in Groovy 6: def data = await api.getDataAsync('42').

For safety, requests — and any redirects they follow — are confined to the configured base URI, so a redirect cannot silently escape to a different host (GROOVY-12182). Where redirects are followed without confinement, HttpBuilder follows them itself and drops the caller’s configured headers for good once a hop leaves the request’s original origin, so an Authorization header, cookie or API key configured on the builder is never sent to whatever origin a Location names. Delegating this to the JDK client was not sufficient: whether the well-known credential headers are stripped varies by JDK update level, and a header the platform does not recognise is forwarded on every JDK (GROOVY-12274).

See the HTTP client user guide for the full API and configuration options.

Contract annotations now work in Groovy scripts, not just inside classes (GROOVY-11885). @Requires and @Ensures can be placed on script methods, and @Invariant can be placed on an import statement to apply as a class-level invariant for the script:

These annotations can be combined to build strong confidence in the correctness of an algorithm. Consider this insertion sort that merges two pre-sorted lists:

The @Ensures postcondition verifies that the result is sorted. The @Invariant asserts that no elements are lost or gained — the total number of elements across all three lists stays constant throughout the loop. The @Decreases annotation uses a lexicographic measure over the two input list sizes, giving us confidence that the loop terminates: on each iteration at least one input list shrinks, and they can never grow.

See also the loop invariants blog post for more on how contracts support correctness reasoning.

The @Requires/@Ensures/@Invariant trio covers normal behaviour. The new @ThrowsIf annotation (GROOVY-12135) covers exceptional behaviour — the guard clause that is otherwise written by hand:

It reads as an iff: the method throws ArithmeticException exactly when b == 0. With the default woven = true, groovy-contracts generates the guard at method entry (the same idea as @NullCheck for the null-check special case); woven = false keeps it as machine-readable documentation only.

A type qualifies as a carrier via any of four routes. The built-in allow-list recognises stdlib and Groovy-core types by class — Optional, Stream, CompletionStage/CompletableFuture, and Awaitable/DataflowVariable — and common FunctionalJava (fj.data.) and Vavr (io.vavr.control.) carriers by fully-qualified name, with no Groovy dependency on those libraries. Beyond the list, any type exposing a single-argument flatMap (plus map) qualifies structurally, and a user type whose method names diverge can opt in with @Monadic (naming its bind/map, and optionally a unit factory for law-checking tooling). GEP-23 has the per-carrier method mapping and the exact shape rules.

Two type-checking extensions back the feature, each activated like any other (@TypeChecked(extensions = '…​')). MonadicChecker — shown in the example above — enforces carrier participation and the closure-return shape of DO chains, and restores the comprehension’s static result type. MonadicShapeChecker is independent of DO: it lints hand-written flatMap/map/thenCompose/thenApply chains, catching a flatMap that returns a non-carrier or a different carrier (which Groovy’s closure coercion would otherwise let through), and the map-returning-M<M<T>> foot-gun. The two compose — code mixing both forms can opt into both.

See GEP-23 for the full specification, the desugaring rules, the carrier-shape requirements, and the relationship to for await / parallel collections / actors and agents.

The NullChecker extension (GROOVY-11894) validates code annotated with @Nullable, @NonNull, and @MonotonicNonNull annotations, detecting null-related errors at compile time. It recognises these annotations by simple name from any package (JSpecify, JSR-305, JetBrains, SpotBugs, Checker Framework, or your own):

Without the null guard, dereferencing a @Nullable parameter produces a compile-time error. The checker also recognises safe navigation, early-exit patterns, @NullCheck, and @MonotonicNonNull for lazy initialisation.

The guard vocabulary covers idiomatic Groovy: Groovy-truth guards (if (x) { x.foo() }), instanceof checks, short-circuit conjunctions (x != null && x.foo()), Objects.nonNull/isNull, assert statements, and guard conditions in while loops and ternaries are all recognised (GROOVY-12208). Nullness is also tracked through expression results, not just variables: the result of a safe navigation used as an unguarded receiver (a?.b.c), a @Nullable-returning call passed straight to a @NonNull parameter, and ternary or Elvis expressions with a nullable branch are all flagged (GROOVY-12209). And nullability metadata is honoured wherever it comes from: type-use annotations and package-level JSpecify-style @NullMarked declarations are read from compiled dependencies on the classpath (including their package-info.class), so precompiled APIs are checked just like source (GROOVY-12206, GROOVY-12207).

Calls that guarantee an argument is non-null when they complete normally narrow that argument afterwards: validator methods such as Objects.requireNonNull(x) (the natural "cast to non-null" escape hatch) and Guava-style checkNotNull(x); test assertions such as assertNotNull(x), with JUnit 4’s (message, actual) and JUnit 5 / TestNG’s (actual, message) argument orders both recognised by parameter types rather than position; and fluent assertion chains like assertThat(x).isNotNull() (AssertJ, Truth, or similar), looking through intermediate chained calls such as describedAs(…​). Consistent with the checker’s design, these methods are matched by simple name, so any library following the common naming conventions is recognised without configuration (GROOVY-12250).

Nullness annotations are also honoured inside type arguments — JSpecify’s headline generics capability. Wherever the static type checker’s generics inference carries a @Nullable type argument through a class or method level type variable, the result is treated as nullable: get(0) on a List<@Nullable String>, the idiomatic subscript xs[0], GDK calls such as head() and first(), and get(key) or m[key] on a Map<String, @Nullable Integer>. The nullable result participates in all the existing analyses — unguarded dereference is flagged, the recognised guards and safe navigation are accepted, and passing it to a @NonNull parameter is an error — whether the annotated type appears in source or is read from a compiled dependency (GROOVY-12252).

Passing strict: true extends the checker with flow-sensitive analysis that detects null issues even in completely unannotated code — no @Nullable, no @NonNull, no special types:

The checker tracks nullability through assignments and control flow, catching potential dereferences that would otherwise surface only at runtime. This is also an example of parameterized type checking extensions in action — the strict: true argument is passed directly in the extension string.

Strict mode also checks that every explicitly-annotated @NonNull instance field is definitely initialized — at its declaration, in an instance initializer block, or by every declared constructor (a constructor delegating via this(…​) relies on its delegate). A @NonNull field nothing ever assigns is otherwise exactly the field the checker would wrongly trust at every dereference:

reports @NonNull field 'catalog' is not initialized by all constructors. Fields that are non-null merely by default (under @NullMarked and friends) are not subject to the check, keeping it noise-free for idiomatic Groovy such as named-argument construction (GROOVY-12251).

See also the NullChecker blog post for a detailed walkthrough.

The parallel Collection reductions (sumParallel, injectParallel) split, reorder, and recombine their input. That is only correct when the combining function is associative — combine(a, combine(b, c)) must equal combine(combine(a, b), c) — and, for the seeded injectParallel, when the seed is an identity. A non-associative combiner (subtraction, division) compiles and runs but produces a different, non-deterministic result depending on how the work was partitioned — among the hardest bug classes to detect by testing alone.

The CombinerChecker extension (GROOVY-12013) verifies at compile time that combiners reaching these methods carry the contract. A combiner declares it with the new @Associative and @Reducer annotations (@Reducer also names an identity element via zero()):

The default (lenient) mode flags only high-confidence problems — a non-associative operator (-, /, %, **) applied directly to the combiner parameters, or an injectParallel seed that contradicts a @Reducer’s declared `zero(). The parameterized strict mode additionally requires the combiner to be a method reference to an annotated method. The checker also recognises Monoid/Semigroup carriers from external libraries, and covers java.util.stream reduce overloads. Since associativity is undecidable in general, this is a conservative, false-positive-averse safety net rather than a proof: the annotations assert the law and are meant to be backed by tests — and because the law is fully specified by the annotation, those tests are machine-actionable and can be auto-derived from the declaration.

The SqlInjectionChecker extension (GROOVY-12187) flags a common SQL-injection smell at compile time: a GString whose interpolated value is placed inside string quotes in a SQL query. Such a value is concatenated into the query text rather than bound as a PreparedStatement parameter, so quoting it defeats `groovy-sql’s placeholder handling (CWE-89):

Like the other bundled checkers it lives in the groovy-typecheckers module and is activated via @TypeChecked(extensions = …​) or a global ASTTransformationCustomizer. It complements the runtime hardening in groovy-sql, which rejects the same quoted-interpolation pattern when a query executes (see Breaking changes and GROOVY-12118).

A trailing *ident captures the remaining elements:

The rest binding works against any RHS supporting either getAt(IntRange) or iterator(). The compiler picks one of three lowerings — a Stream rewrap that keeps lazy pipelines lazy, an getAt(IntRange) slice (whose return type drives the rest binder’s type), or an iterator fallback that supports unbounded sources without materialising them:

*ident in non-tail position lowers via indexed access against a sized, indexable RHS:

key: ident pairs in the declarator list bind via property access (map keys, JavaBean getters, or getProperty via the MOP):

The rest binder may carry a type ascription, mirroring the existing positional form:

For symmetry with switch case patterns and bracket-form declarations, def and var may appear before any binder; they are equivalent to omitting a type. Modifiers on the outer declaration propagate to every binder (including rest and map-style):

The "discard" convention, e.g. def (_, y, m) = Calendar.instance, applies uniformly across every new form. _ is a regular identifier throughout — no wildcard semantics, no special parser node:

Several variants of groupByMany (GROOVY-11808) exist for grouping lists, arrays, and maps of items by multiple keys — similar to Eclipse Collections' groupByEach and a natural fit for many-to-many relationships that SQL handles with GROUP BY.

The most common form takes a closure that maps each item to a list of keys:

For maps whose values are already lists, a no-args variant groups keys by their values:

A two-closure form also exists for transforming both keys and values. See the groupByMany blog post for more examples including Eclipse Collections interop.

waitForResult replaces the manual stream/exit-code dance with a single call (GROOVY-11901):

Process output streams are now decoded using the system’s native encoding rather than the JVM default charset, which is what most command-line tools actually emit. Set -Dgroovy.process.encoding=<charset> to override it explicitly (GROOVY-12155).

The groovy-nio module adds async file operations on Path that return CompletableFuture results (GROOVY-11902). These compose naturally with Groovy 6’s async/await:

Capturing regex groups was always possible via Matcher (m[0][1] and friends), but the common case — pull a few named pieces out of a string — meant juggling group indices and guarding against a non-match. findGroups returns the full match followed by each capture group as a List, so it pairs naturally with multi-assignment. This isn’t new capability; it just removes the Matcher boilerplate from one very common case (GROOVY-11958):

For the balanced, properly-nested case that a plain regex cannot match on its own, the new findBalancedGroups GDK method returns the spans between a matching open/close pair (parentheses, brackets, tags, …​) (GROOVY-12133):

The GDK gains locale-aware currency and percent formatting, plus locale-aware parsing, wrapping java.text.NumberFormat to cover cases that sprintf/String.format structurally cannot — currency conversion and percent scaling/placement (GROOVY-12147):

The formatting methods are Number.toCurrencyString([Locale]) and Number.toPercentString([Locale]); the parsing methods are CharSequence.toNumber(Locale), toCurrencyNumber([Locale]), and toPercentNumber([Locale]), each returning a Number. The overloads without a Locale use the default locale, so a localized percent such as German 94,5 % round-trips via toPercentString() / toPercentNumber(Locale.GERMANY).

Two new GDK methods cover common "look at neighbours" list operations that previously needed index juggling or a manual fold (GROOVY-12016).

zipWithNext pairs each element with its successor, optionally combining each pair — handy for deltas, ratios, or detecting transitions:

groupConsecutive splits an iterable into maximal runs — by equality, by a key function, or by an adjacency predicate (note: only consecutive equal keys group together, unlike groupBy):

Both have lazy Iterator variants and array overloads, so they compose with other sequence operations without materialising intermediates.

Many of Groovy’s higher-order extension methods now have overloads that accept java.util.function SAM types — Predicate, Function, Consumer, BiPredicate, BiFunction, and friends — directly, instead of requiring a Closure wrapper (GROOVY-12034, GROOVY-12054). Passing a lambda or method reference straight through avoids the per-call Closure allocation — "fat-free" — and improves interop with Java APIs that already hand you java.util.function values. The standard overloads mirror the existing Closure forms one-for-one, covering each/eachWithIndex, collect/collectEntries, collectMany, groupBy, countBy, split, takeWhile/dropWhile, inject/injectAll, any/every, find/findAll, count, and the lazy collecting/collectingMany/findingAll iterator variants (GROOVY-12215, GROOVY-12216). Map receivers take the two-argument forms (BiFunction/BiPredicate), and the fold/reduce forms take a BinaryOperator when no initial value is given, or a BiFunction when one is. Array receivers have the same twins (GROOVY-12218), including any/every/count overloads on int[], long[] and double[] accepting IntPredicate/LongPredicate/DoublePredicate — giving primitive arrays a predicate form of count for the first time. Under @TypeChecked / @CompileStatic, a method reference or lambda argument now selects the functional-interface overload when a Closure overload also applies, so these calls type-check and compile statically (GROOVY-12214).

A companion curryWith helper (in org.apache.groovy.util.Lambdas, and in org.apache.groovy.util.Closures for hybrid results usable as both a Closure and a java.util.function type) right-partials a two-argument SAM by fixing its second argument, so a shared BiPredicate/BiFunction can be reused across calls without a capturing closure:

A matching set of incubating …​(self, BiPredicate/BiFunction, param) overloads bake this right-curry in directly — list.find(condition, param) is equivalent to list.find(curryWith(condition, param)) — covering collect/collecting, find/findAll/findingAll, any/every, and count:

GINQ’s groupby clause now supports an into keyword (GROOVY-11915) that binds each group to a named variable with aggregate access:

SQL-style set operators (GROOVY-11919) for combining query results: union, intersect, minus, and unionall:

See the GINQ user guide for the full set of clauses and operators.

CsvSlurper parses CSV text into a list of maps, keyed by column headers:

The separator and quote characters can be customised via fluent setters, and quoted fields follow RFC 4180 rules (embedded commas, newlines, and doubled quotes). Set useHeader = false to treat the first row as data and key rows by auto-generated column names. Reader/InputStream/File/Path overloads of parse are provided alongside parseText.

CsvBuilder converts collections of maps to CSV:

When Jackson is on the classpath, CsvSlurper can parse CSV directly into typed objects, and CsvBuilder can write typed objects to CSV. This is particularly useful for CSV since all values are strings — Jackson handles conversion to numeric, date, and other types automatically:

See the Processing CSV user guide for the full API and configuration options.

XXE attacks, billion-laughs entity expansion, and unintended network access via external DTDs all stem from JDK XML factories that ship with permissive defaults. The front-line Groovy parsers — XmlParser, XmlSlurper, the static DOMBuilder.parse(…​) overloads, and XmlUtil.newSAXParser — were already secure-by-default. Groovy 6 closes the remaining gaps in XmlUtil.serialize, FactorySupport, and DOMBuilder.newInstance (GROOVY-11979, GROOVY-11981) — see Breaking changes for the per-API migration knobs. A new XML security chapter in the user guide documents the contract end-to-end.

Two new XmlUtil methods stream over XML sources without loading the whole document into memory (GROOVY-11979): events(reader) returns a Stream<XMLEvent>, and streamElements(reader, [namespaceURI,] localName) pulls each matching subtree as a small DOM Node. Both run on a hardened XMLInputFactory, so streaming an untrusted feed is safe out of the box.

Combined with the new HttpBuilder, we can fetch a published Groovy pom from Maven Central and extract its license:

The lower-level events API suits counts and scans where a DOM Node per match would be wasteful — counting <dependency> entries across both dependencyManagement and dependencies is a single filter:

MarkdownSlurper parses Markdown text into a MarkdownDocument backed by nested lists and maps. Each node is a Map with a type key plus type-specific fields:

The document exposes convenience properties — headings, codeBlocks, links, tables — that recursively walk the tree, so nodes nested inside list items or block quotes are still found. A text property gives a plain-text projection of the whole document with formatting markers stripped.

The slurper is resilient to malformed input, capping nesting depth (default 1000) to avoid stack overflow on pathological documents. The limit is configurable per parser via setMaxNestingDepth(int) (a value ⇐ 0 disables the check) or globally with the groovy.markdown.maxNestingDepth system property (GROOVY-12183).

Pulling fenced code blocks by language is a common pattern when consuming LLM output:

section(headingText) returns the nodes between a given heading and the next heading of equal or higher level — handy for parsing structured agent replies:

GFM-style tables are supported when the org.commonmark:commonmark-ext-gfm-tables jar is on the classpath. Call enableTables(true) on the slurper and each row comes back as a Map keyed by header:

Supported node types include heading, paragraph, code_block, list/list_item, block_quote, link, image, text, inline_code, emphasis/strong, html_block/html_inline, thematic_break, line breaks, and (with the GFM extension) table.

See the Processing Markdown user guide for the full node schema and additional examples.

Both engines respect the grape.root system property for relocating the cache root.

When both engines are on the classpath, GrapeIvy is selected by default. To switch to GrapeMaven for a specific invocation:

Set the same property in JAVA_OPTS for a global default.

Custom GrapeEngine implementations are discovered via the standard java.util.ServiceLoader mechanism by including a jar with a META-INF/services/groovy.grape.GrapeEngine entry naming the implementation class. See the user guide for the full registration protocol.

Most existing @Grab scripts work unchanged with both engines. The notable differences when moving from GrapeIvy to GrapeMaven:

Switching from GrapeMaven back to GrapeIvy is generally straightforward since GrapeIvy’s defaults are more permissive.

See the Grape user guide for the full per-engine specification, custom-engine registration steps, per-engine logging configuration, and detailed migration walkthrough.

The grape install command line tool now accepts the same Maven and Ivy coordinate shorthands as @Grab and the Grape facade, in addition to its original positional form (GROOVY-12004):

The static Grape.grab(String) Java API has been broadened along the same lines: in addition to its existing endorsed-module notation it now recognises both shorthand forms, dispatching to grab(Map) once the coordinate has been parsed.

Grape resolution has been hardened against several real-world failure modes (GROOVY-12005):

Groovy’s command-line tools resolve logging configuration in the following order (first match wins):

For example, to enable verbose Grape logging, create ~/.groovy/logging.properties with:

Loggers are organised by module (Core, Grape, Ant, Console, GroovyDoc, JSON, Servlet, Swing, Testing) — see the logging guide for the full list of logger names and their levels.

Application logging has the opposite problem: a logging framework finds the caller of a log statement by walking the stack, and every frame Groovy’s runtime inserts between the two — metaclass dispatch, the reflective cold dispatch tier, GraalVM’s method-handle interpreter in a native image — makes that answer wrong, so a pattern using %C/%M/%L names the runtime rather than the code that logged. Log4j2 offers no skip list to configure, but it does let a caller supply the location, and an AST transform knows that location exactly, because it is the one writing the call.

@Log4j2 gains a staticLocation option that does just that (GROOVY-12378):

The statement is emitted as log.atInfo().withLocation(loc).log("placing $order"), where loc is a StackTraceElement for that statement held in a synthetic static field. So %C, %M and %L report OrderService.place and its line however the call was dispatched — and Log4j2 skips its stack walk altogether, which is the expensive part of resolving a location. A leading Marker or trailing Throwable argument is routed through withMarker/withThrowable at run time, since the builder does not extract a message’s throwable itself.

It is opt-in because the call shape changes and LogBuilder requires Log4j 2.13+, which the transform checks at compile time. For the wider picture of which dispatch paths make the caller invisible, and the java.util.logging and Logback settings that compensate on the paths a transform cannot rewrite, see the invokedynamic guide and Other Core API Changes.

For most users, no special Groovy module is needed — simply add the standard JUnit Jupiter dependencies to your Gradle or Maven project and write tests in Groovy as usual:

The new groovy-test-junit6 module provides additional capabilities for users who need them:

Similarly, the existing groovy-test-junit5 module continues to provide the same capabilities for JUnit 5 users.

The new /img command renders an image inline in the REPL using JLine’s terminal-graphics support (Sixel, Kitty, or iTerm2 protocols, auto-detected) (GROOVY-12003). The argument can be a local file path, an http(s):// URL, or a Groovy variable reference using the standard $ syntax:

When the argument resolves to a Groovy value, /img accepts a BufferedImage or RenderedImage directly, anything with a createBufferedImage(int, int) or toBufferedImage(int, int) method (duck-typed — no compile-time dependency), or a javax.swing.JComponent that is laid out and painted at the requested size. This means popular charting libraries can be rendered in the REPL without saving to a file first. JFreeChart matches the createBufferedImage shape, Smile’s Figure matches toBufferedImage, Smile’s Canvas/MultiFigurePane and Orson Charts' Chart3DPanel match the JComponent path, and XChart’s BitmapEncoder.getBufferedImage(chart) returns a plain BufferedImage. For example, a JFreeChart bar chart:

Or feeding CSV through the existing /slurp command into an XChart line plot:

The --width and --height options are in terminal character cells for raw-pixel inputs and in source-image pixels for inputs that generate the image at the requested size; aspect ratio is preserved by default. If the active terminal doesn’t speak a supported graphics protocol (common cases: macOS Terminal.app, VS Code’s built-in terminal, JetBrains terminals, plain Windows console), /img prints a [image: WxH, label] summary instead — pass --gui to open a Swing window with the image regardless. The command requires the java.desktop module at runtime; on a JVM where that module is unavailable, /img is not registered.

The /slurp command — a shortcut for parsing files into shared variables using Groovy’s various slurpers (JSON, XML, YAML, CSV, TOML, properties) — now also handles Markdown (GROOVY-12002). Files with .md or .markdown extensions are routed through the new MarkdownSlurper from groovy-markdown (when it is on the classpath), yielding a MarkdownDocument that exposes structured elements — headings, code blocks, links, tables — via the iterator and convenience properties documented in that module. Combined with /img above, this enables short pipelines from Markdown reports into rendered charts directly in the REPL.

Highlight-style names supplied to /print -s <FORMAT> (and the /highlighter switch) are now resolved case-insensitively, so json, JSON, and Json all select the same nanorc grammar (GROOVY-12018).

GroovyDoc gained a -theme flag controlling the output palette strategy (GROOVY-11947):

The default stylesheet has been refactored around semantic CSS custom properties (--fg, --bg, --link, --bg-panel, etc.), so author stylesheets supplied via --add-stylesheet can reference the same tokens and become theme-aware automatically — the same hook that enables fully custom palettes. When Prism.js syntax highlighting is enabled, the highlight theme swaps in sync with the page palette (GROOVY-11946).

The same theming model has been extended to docgenerator, the tool that produces the Groovy user guide and other distribution-bundled documentation. Output supports light, dark, and custom themes, following the OS preference by default and sharing the GroovyDoc CSS-custom-property approach so that custom stylesheets remain palette-aware.

GroovyConsole now offers light, dark, follow-system, and custom theme options, applied across the editor pane, output pane, and surrounding chrome. The active choice is persisted between sessions.

A run of /// line comments can now be used as a doc comment whose body is CommonMark Markdown (GROOVY-11542):

Headings, bullets, fenced code blocks, emphasis, and inline code all render as you would expect. Headings are shifted down two levels (so # becomes <h3>), fitting under each page’s existing title structure. Inline Javadoc tags continue to work inside Markdown bodies; tag-like text inside fenced code blocks stays literal. Traditional /** …​ */ Javadoc blocks still work and can coexist with /// comments in the same source file.

See JEP 467 and CommonMark for the full syntax and semantics.

The JEP 413 {@snippet} tag is now supported (GROOVY-11938) in three forms. Inline body:

External reference to a file in the package’s snippet-files/ directory (a region can also be selected via region="name"):

Markup comments inside snippet bodies let authors highlight, replace, or link to portions of the code without editing the source itself:

@highlight, @replace, and @link all support substring=, regex=, and region= attributes. See JEP 413 for the full markup reference.

Two author-facing conveniences apply to the external form: the language class is inferred from the file’s extension when no explicit lang="…​" is given, and a leading license or copyright header in the referenced file is stripped from the rendered output (opt out with keepHeader=true). See the dochome:groovydoc.html[Groovydoc documentation] for the full list of recognised extensions and the header-detection heuristic.

Two new generator flags make the rendered output immediately more modern:

-syntaxHighlighter=prism bundles Prism.js for client-side syntax highlighting of {@snippet} blocks and Markdown fenced code. Groovy, Java, XML, JSON, YAML, TOML, SQL, CSV, Markdown, JavaScript, and regex are supported out of the box.

-theme controls the palette strategy (GROOVY-11947):

Under the hood, the default stylesheet has been refactored around semantic CSS custom properties (--fg, --bg, --link, --bg-panel, etc.). Author stylesheets supplied via --add-stylesheet can reference the same tokens and become theme-aware automatically.

The new -preLanguage <lang> option (CLI) / preLanguage="lang" attribute (Ant task) sets a default Prism language for unattributed <pre> blocks in doc comments, so legacy code samples get highlighted without source edits (GROOVY-11950). See the dochome6:groovydoc.html[Groovydoc documentation] for the rewrite rules and the per-block opt-out.

Smaller improvements that collectively close the long-standing gap with modern Javadoc:

The new options above are exposed through the GroovyDoc CLI (groovydoc) and the Ant task. Gradle’s built-in groovydoc task currently lags behind both surfaces and does not yet expose every new flag.

Until that gap closes, we recommend either driving GroovyDoc via the Ant task from Gradle, or replicating the approach used by the Apache Groovy and Grails builds themselves — both projects wrap GroovyDoc in their own plugin/build glue to access the full feature set.

Groovy 6 supports Java’s module import declarations (GROOVY-11896), giving scripts and classes a concise way to pull in every public type exported by a named module with a single statement:

An import module java.sql is equivalent to a star import (import pkg.*) for every package the module exports, and also covers packages reached via requires transitive. For example, a single import module java.sql makes Connection and DriverManager directly available, along with types like javax.xml.transform.Source (from java.xml) and java.util.logging.Logger (from java.logging).

Module imports work with system modules (JDK modules like java.base, java.sql, java.desktop), JPMS modules from modular JARs on the classpath, and automatic modules. Explicit single-type imports take priority, so naming conflicts can be resolved by adding a specific import:

The module keyword is context-sensitive — it remains usable as a variable, method, or class name. Wildcard (import module java.base.*) and alias (import module java.base as jb) forms are not supported. See JEP 511 for the corresponding Java language feature.

Labelled break targeting a labelled (non-loop) block now correctly exits that block, matching Java. Previously the break exited only the innermost enclosing loop, causing statements after the labelled block to re-execute (GROOVY-6844, GROOVY-7463).

Pattern variables introduced by instanceof (and Groovy’s native !instanceof) now follow Java’s flow scoping rules (JEP 394): the variable is in scope exactly where the compiler can prove the test succeeded (GROOVY-12242). In particular, the Java-idiomatic early-return form now works:

Flow scoping composes through !, && and || in the condition: o instanceof String s && s.length() > 4 binds s for the right-hand side of the && and for the if-block, a negated test binds the else-block, and the variable remains bound after the whole statement when the branch it is not bound in cannot complete normally (as above). Where flow scoping says the variable is not bound — the else-block of a plain instanceof test, or anywhere after o instanceof String s || other — a same-named declaration is now permitted and introduces an ordinary new local. Reads outside the flow scope are compile-time errors under @TypeChecked / @CompileStatic and dynamic property lookups in dynamic code; this is a behaviour change for code that relied on the previous leaking scope (see Breaking changes). while conditions support the short-circuit and loop-body bindings; Java’s introduction of the variable after a loop whose body cannot complete normally is not currently applied.

Groovy 6 accepts Java’s intersection-type cast syntax on lambdas, method references and closures, so that a single expression can be declared to satisfy several interface contracts at once (GROOVY-11998):

The cast carries through static compilation: when one of the bounds is Serializable, the generated synthetic class implements Serializable and emits the required $deserializeLambda$ plumbing, so the resulting lambda can be persisted, sent across JVMs, or used in frameworks that rely on serialised lambdas (such as JPA Criteria APIs and some distributed-computing libraries). The same applies to method references (GROOVY-11993) — a (Supplier<String> & Serializable)-typed text::trim survives a round-trip through ObjectOutputStream/ObjectInputStream.

The non-functional bounds are passed through to LambdaMetafactory as marker interfaces, so reflective checks (instanceof Serializable, instanceof Cloneable, …​) on the resulting object behave as Java programmers expect.

In addition to the Java-style cast, Groovy’s as coercion accepts the same intersection form — handy when coercing a closure rather than a lambda:

Groovy 6 closes the remaining gaps between Groovy’s and Java’s handling of generic type syntax (GROOVY-12319), so generic declarations copied from Java source mean the same thing in Groovy. Three strands:

Rare types and nested parameterizations. The JLS 4.5 enclosing type is now carried on the ClassNode itself, so Outer<String>.Inner is distinguished from Outer.Inner and written into the JVMS Signature attribute in its nested form when — and only when — the enclosing type is parameterized. Map.Entry and Cell.class are recognised as type names rather than parameterizations (JLS 15.8.2), and method and constructor references such as Iterable<String>::iterator are no longer mistaken for class literals.

Type variables identified by declaration. A GenericsType now records which type-parameter section declared it, so two placeholders both named T are distinguished when they come from different declarations — a method’s T can no longer be stored in a field typed by the class’s T. An unbounded type-parameter declaration no longer inherits a shadowed variable’s erasure, and duplicate names within one type-parameter section are rejected.

JLS well-formedness. Every compilation unit — dynamic Groovy and scripts included — now requires generic types to be well-formed by the same JLS rules Java applies. Constructs such as generic array creation (new T[n]), a generic class extending Throwable, a wildcard in a class instance creation or superinterface, a primitive type argument, a parameterized class literal (Foo<String>.class), instantiating or naming a type variable, and catching a type parameter (JLS 14.20) are compile errors where Groovy 4 and 5 accepted them by silently falling back to the erasure. Diagnostics for these — and for static references to a type parameter, wildcard bounds, instanceof of rare and array types, and duplicate generic interfaces — are worded to match javac. This tightening is a behaviour change; see Breaking changes, and the Generics section of the dochome6:core-object-orientation.html#generics-well-formedness[object orientation guide] for the full table of rejected constructs with their workarounds.

What has not changed is inference: dynamic Groovy still does not check generic invariance, inference, or unchecked conversions — those remain the domain of @TypeChecked and @CompileStatic.

Java’s Security Manager has been deprecated for removal by JEP 411, which argues that it is rarely used to secure modern applications and that security is better achieved through other mechanisms such as containers and operating system security.

Groovy 6 removes its use of AccessController.doPrivileged calls and related Security Manager infrastructure (GROOVY-10581). Code that relied on Groovy’s Security Manager integration should adopt alternative security mechanisms. Groovy 5 still includes such support on JDK versions that support it.