Groovy 5.0.x support for Grails 8 + Spring Boot 4

[jamesfredley]

Adds Apache Groovy 5 support on top of 8.0.x, tracking the pre-release Apache Groovy 5.0.7-SNAPSHOT development build.

Note on the version pin: This PR previously pinned the released 5.0.7 coordinate. Groovy 5.0.7 has not actually shipped yet (the GROOVY_5_0_X branch is still 5.0.7-SNAPSHOT), and the experimental @Anchored trait-static annotation this PR briefly relied on was voted down by the Groovy PMC and removed upstream (GROOVY-12093, "out with @Anchored in with @Virtual"). We therefore track 5.0.7-SNAPSHOT.

The PR is now narrowed to the Grails-side workarounds and adaptations still needed after the fixes that landed in Groovy 5.0.7-SNAPSHOT.

Target stack

Component	Version
Apache Groovy	5.0.7-SNAPSHOT
Spock	2.4-groovy-5.0
Spring Boot	4.x on the 8.0.x line
Spring Framework	7.0.x
Jakarta EE	10
JDK	21+

End-application impact

Default Grails 8 applications that use the Grails Gradle plugin and the default platform(grails-bom) dependency management should not need build-script changes for this Groovy 5 update.

Applications that intentionally opt out of the default Grails BOM path still need to keep Groovy and Spock aligned with the Grails BOM. In particular, apps using grails { bom = null } plus io.spring.dependency-management, or Spring Boot applications consuming Grails GSP modules outside the normal Grails platform path, must import org.apache.grails:grails-bom and align groovy.version / spock.version with it.

Application code compiled with @CompileStatic / @GrailsCompileStatic should also account for the Groovy 5 behavior changes already documented in the upgrade guide updates in this PR:

• Static field assignment inside static closures such as constraints, mapping, or namedQueries should qualify the field with the class name.
• Raw ConfigObject probes that expect missing keys to be null should use containsKey(key) ? config.get(key) : null, since config[key] now creates an empty nested ConfigObject for missing keys.

Grails-side workarounds and adaptations

Site	Why Grails still has code here	Current handling
ConstrainedProperty.DEFAULT_MESSAGES	GROOVY-12063 remains open.	Uses a Groovy map literal, then wraps it immutable, so sibling default-message constants resolve against the enclosing interface scope rather than as dynamic reads against an empty HashMap initializer receiver.
GroovyPageTypeCheckingExtension and ControllerTagLibTypeCheckingExtension	Groovy 5 intentionally pre-resolves getProperty(String) receivers as dynamic before unresolvedVariable / unresolvedProperty callbacks can record Grails taglib namespace dispatch.	Uses StaticTypesMarker.DYNAMIC_RESOLUTION to recognize taglib namespace receivers, while still requiring GSP receiver names to be configured taglib namespaces.
GroovyPageTypeCheckingExtension GSP undeclared-variable validation	Grails wants compile-static GSP model expressions to keep failing for unknown bare variables, even though Groovy 5 can dynamically resolve them through the inherited getProperty(String) path.	Adds a Grails-side pass over dynamic-resolution variable expressions and reports non-taglib bare variables as undeclared. The negative GspCompileStaticSpec checks are enabled again.
grails-test-examples/gsp-spring-boot Spring Dependency Management example	CI can refresh a stale remote 8.0.0-SNAPSHOT BOM before the updated snapshot is published, letting Spring DM downgrade SiteMesh Spring artifacts to an unpublished version.	Explicitly manages the SiteMesh Spring artifacts from the checked-out dependencies.gradle values while still importing grails-bom, keeping this regression example deterministic in CI.

Local verification for the latest update

• ./gradlew :grails-data-graphql-core:compileGroovy --refresh-dependencies (against the published 5.0.7-SNAPSHOT, build 20) - succeeds; the previously failing Arguable/ComplexTyped#withDelegate(Closure, Object) STC error is gone.
• ./gradlew :grails-data-graphql-core:test
• ./gradlew :grails-data-graphql-core:codeStyle
• git diff --check

[jamesfredley]

Update: tracking 5.0.7-SNAPSHOT again + new GraphQL trait-static workaround

Pushed 0035ca1b58.

Why the version moved back to a snapshot. This PR had pinned the released Groovy 5.0.7 coordinate. Two problems:

1. Groovy 5.0.7 has not actually shipped - the GROOVY_5_0_X branch is still 5.0.7-SNAPSHOT.
2. The experimental @Anchored trait-static annotation this PR briefly relied on was voted down by the Groovy PMC and removed upstream in GROOVY-12093 (commit e83dd19b, "out with @Anchored in with @Virtual"). groovy.transform.Anchored no longer exists; it is replaced by groovy.transform.Virtual.

So dependencies.gradle now tracks 5.0.7-SNAPSHOT (the build that contains the replacement model), and the affected Grails-side workaround is adapted to it.

Why @Virtual is not a drop-in replacement here. @Anchored let a child trait call a parent trait's static helper (ExecutesClosures.withDelegate(...)) under @CompileStatic. The replacement @Virtual does something different: it only restores per-implementer override dispatch for calls made from the same trait or an implementing class (the Validateable.defaultNullable()-style hook). It does not make a child @CompileStatic trait resolve an inherited parent-trait static. I verified this empirically with full Gradle compiles against a freshly re-downloaded 5.0.7-SNAPSHOT:

Attempt	Result
plain static + ExecutesClosures.withDelegate(...) (qualified)	STC error: Cannot find matching method java.lang.Class#withDelegate(...)
@Virtual + ExecutesClosures.withDelegate(...) (qualified)	same java.lang.Class#withDelegate error
@Virtual + withDelegate(...) (unqualified, inherited)	STC error: Cannot find matching method ...Arguable#withDelegate(...)

This matches Groovy's own TraitStaticDispatchMatrix (rows 7/8: trait-qualified static access throws / is unsupported) and VirtualAnnotationTest (every @Virtual case is a same-trait or implementing-class call, never a child-trait→parent-trait inherited static).

The workaround. Since no @Virtual call form compiles for the cross-trait case, the GraphQL helper goes back to the approach that predated @Anchored:

• ExecutesClosures.withDelegate stays a plain static method (still the trait's public contract for implementing classes - just without @Anchored/@Virtual).
• Arguable and ComplexTyped re-inline the null-safe DELEGATE_ONLY closure logic instead of calling the parent-trait static.

Verification (against fresh 5.0.7-SNAPSHOT, Groovy snapshot caches flushed before re-resolve):

• ./gradlew :grails-data-graphql-core:compileGroovy :grails-data-graphql-core:compileTestGroovy --rerun-tasks --refresh-dependencies - BUILD SUCCESSFUL
• ./gradlew :grails-data-graphql-core:test - all specs PASSED
• ./gradlew :grails-data-graphql-core:codeStyle - PASSED (Checkstyle + CodeNarc)
• git diff --check - clean

[jamesfredley]

Deep-dive: the withDelegate trait-static problem is GROOVY-12106, and it is still broken on 5.0.7-SNAPSHOT

I dug into why the GraphQL sub-traits cannot call the inherited ExecutesClosures.withDelegate static, since it is the one thing keeping the inline-duplication workaround in this PR.

Standalone reproducer: https://github.com/jamesfredley/groovy-12106-repro (pure Groovy + Gradle, ./gradlew compileGroovy fails on 5.0.7-SNAPSHOT).

Root cause

Under @CompileStatic, when a child trait extends a parent trait and calls an inherited static helper, STC misroutes the call to the child trait's helper with a synthetic $self:

Cannot find matching method Arguable$Trait$Helper#withDelegate(java.lang.Class, groovy.lang.Closure, SimpleArgument)

The decisive trigger (found by bisection): an argument whose static type is a proper subtype of the declared parameter type. With withDelegate(Closure, Object), calling it with a CustomArgument/Field (subtypes of Object) fails; calling it with an exact Object resolves fine. @DelegatesTo, a stateful trait field, and the presence of an implementer were all ruled out as necessary - only the subtype argument is required to reproduce the minimal case.

This is exactly why GROOVY-12106 (which I filed) was closed Resolved / Cannot Reproduce: a naive minimal repro passes exact-typed arguments and compiles. The subtype case still fails on the current GROOVY_5_0_X tip - the repo above demonstrates it and I think the issue should be reopened with it.

What does NOT fix it

• @groovy.transform.Virtual (the replacement for the removed @Anchored): only restores per-implementer override dispatch for same-trait / implementing-class calls; it does not make a child trait resolve an inherited parent-trait static. Adding it does not change the failure.
• Casting the argument to the exact parameter type (withDelegate(closure, (Object) argument)) fixes the minimal case, but in the full grails-data-graphql-core module it is still not sufficient (the real traits then fail with Arguable#withDelegate(Closure, Object) not found). So a cast is not a usable workaround for this PR.

Conclusion for this PR

The inline-duplication workaround already on this branch stays as the only reliable option until the Groovy STC fix lands. Once GROOVY-12106 is genuinely fixed in a 5.0.7-SNAPSHOT build, the inlined blocks in Arguable / ComplexTyped can be deleted and replaced with a plain withDelegate(closure, argument) call. I left // GROOVY-12106 markers on the inlined blocks so they are easy to find and remove later.

Also fixed: the related Validateable.defaultNullable() CI failure

The same finalized Groovy 5 trait-static model broke the other direction. After the 5.0.7-SNAPSHOT switch, ValidateableTraitSpec had 2 failures (constraints nullable-by-default when overridden; overridden-defaultNullable properties not accessed during validation). Root cause: Validateable's trait body calls this.defaultNullable(), and under the new declarer-bound default a plain trait static returns the trait's own false instead of an implementing class's override. Fix: annotate Validateable.defaultNullable() with @groovy.transform.Virtual (the matrix-documented "Grails Validateable.defaultNullable" use case) so the override is seen by trait-body calls. :grails-validation:test + :grails-validation:codeStyle now pass. External callers are unaffected (reflective static invocation / compile-time boolean).

[jamesfredley]

**Arguable / ComplexTyped GROOVY-12106 fix does not cover the Grails shape, because it is order-dependent.

• The fix (b7796c3f9b, PR GRAILS-5598: GSP expressions in HTML attributes cause exception if separated by a whitespace #2635) is entirely in TraitTypeCheckingExtension - the STC layer. It does subtype-aware lookup over the super-trait helper's declared statics, but only after the call has already been rewritten into …$Trait$Helper.withDelegate($static$self, closure, arg) form.
• That rewrite happens earlier, in TraitReceiverTransformer.findConcreteMethod. If the super-trait's $Trait$Helper has not been generated yet when the sub-trait body is transformed, findConcreteMethod returns null and the call is left as a plain Arguable#withDelegate(Closure, Object) - so the fixed STC branch (which keys off isClassType(argumentTypes[0]), i.e. the synthetic $static$self Class arg) is never entered.
• In this module the files sort Arguable / ComplexTyped before ExecutesClosures alphabetically, so the sub-traits are transformed first and hit exactly this gap. Groovy's own passing test Groovy12106.testGrailsHelperShapeWithDelegatesTo declares the parent trait first in a single script, so it never triggers the ordering.

Proof - minimal self-contained reproducer compiled against build 18 (and against a local Groovy build from b46ebb25e7):

import groovy.transform.CompileStatic
final class FieldA {}

@CompileStatic
trait ArguableA<T> extends ExecutesClosuresA {          // sub-trait declared FIRST
    String describe(FieldA f) { withDelegate({ -> }, (Object) f); 'ok' }
}
@CompileStatic
trait ExecutesClosuresA {
    static void withDelegate(@DelegatesTo(strategy = Closure.DELEGATE_ONLY) Closure c, Object d) { if (c != null) c.call() }
}
class CA implements ArguableA<String> {}

• Sub-trait-first (above) → fails: Cannot find matching method ArguableA#withDelegate(groovy.lang.Closure, java.lang.Object) - the exact Grails error.
• Reverse the two trait declarations (super-trait first) → compiles.

This is essentially Groovy12106.testGrailsHelperShapeWithDelegatesTo with only the declaration order reversed. It looks like a distinct upstream transform-order defect, earlier than the 12106 STC fix - reminiscent of the older GROOVY-11743 "super trait may not be transformed when creating helper". Worth a follow-up ticket for Paul with the reproducer above (the real fix would be in TraitReceiverTransformer.findConcreteMethod: fall back to the super-trait's declared statics when its helper is not yet generated, or order helper generation before sub-trait body rewriting).

Grails-side escape hatches tried and rejected: plain withDelegate(closure, argument), (Object)-cast, this.withDelegate(...), and making withDelegate an instance method all fail - the instance + @DelegatesTo form fails to bind (Not enough arguments found for a @DelegatesTo method call), and withDelegate is used across ~8 GraphQL files, so a signature change is invasive. So the inline stays.

The in-code comments and the PR description have been corrected to this root cause in 12292b860b. The inline can drop to the byte-identical 8.0.x withDelegate(closure, (Object)…) call once the upstream transform-order gap is fixed.

Assisted-by: claude-code:claude-4.8-opus

[jamesfredley]

GROOVY-12117: tested the dedicated transform-order fix locally - GraphQL inline must stay

The withDelegate trait-static gap now has its own ticket, GROOVY-12117 ("resolution of inherited static trait method from sub-trait body is transform-order dependent"), and the fix landed on GROOVY_5_0_X as commit fcab925d21. The Apache snapshot publish for it failed in CI (run 28402000859), so it never reached repository.apache.org - the published 5.0.7-SNAPSHOT (build 19, 5.0.7-20260629.205749-19) does not contain it. I therefore tested the fix from a local build.

What I did:

• Checked out GROOVY_5_0_X tip at fcab925d21 (the GROOVY-12117 fix) and ./gradlew publishToMavenLocal (5.0.7-SNAPSHOT).
• Purged every org.apache.groovy:*:5.0.7-SNAPSHOT artifact from the Gradle cache so nothing remote could shadow it.
• Removed the Arguable / ComplexTyped inline and restored the plain withDelegate(closure, (Object)…) call.
• Compiled with GRAILS_INCLUDE_MAVEN_LOCAL=1, which puts mavenLocal() first in dependency resolution. Confirmed via dependencyInsight + an empty remote-snapshot cache that groovy resolved from mavenLocal (the fix build).

Result:

Configuration (groovy = local fcab925d21 build)	:grails-data-graphql-core:compileGroovy
Workaround removed (plain withDelegate(closure, (Object)…))	FAILS - Cannot find matching method Arguable#withDelegate(Closure, Object) / ComplexTyped#withDelegate(Closure, Object)
Workaround kept (inline DELEGATE_ONLY)	compiles green

So the GROOVY-12117 fix, as it currently stands on GROOVY_5_0_X, still does not cover the Grails sub-trait-before-super-trait module layout (Arguable/ComplexTyped sort alphabetically before ExecutesClosures, so they are transformed before the super-trait's $Trait$Helper exists and TraitReceiverTransformer skips the rewrite the fixed STC branch keys off). The inline workaround stays for now.

Updated the workarounds table at the top of the PR and the in-code // GROOVY-12117 markers to cite this ticket and the local-build verification. The inline can drop to the byte-identical 8.0.x withDelegate(closure, (Object)…) call once GROOVY-12117 is fixed for the transform-order case and a fixed snapshot publishes.

Assisted-by: claude-code:claude-4.8-opus

[jamesfredley]

GROOVY-12106 fixed upstream - GraphQL trait-static workaround removed

Paul King pushed the GROOVY-12106 port to GROOVY_5_0_X (apache/groovy@67198d4), and this time it lands the case Grails actually hits.

Why this commit fixes our case. Earlier the STC fix was order-dependent: it only engaged after TraitReceiverTransformer rewrote the unqualified inherited static call into super-trait helper-static form, which is skipped when a sub-trait is transformed before the super-trait's $Trait$Helper exists - exactly our layout, since Arguable/ComplexTyped sort alphabetically before ExecutesClosures. The new commit makes TraitReceiverTransformer.findConcreteMethod resolve the original static on the trait node even when findHelper returns null (which is what happens on 5.0.x for the not-yet-lowered super trait), so the rewrite is no longer skipped in the sub-trait-first ordering.

The good part: it is in the published snapshot, so no local Groovy build is needed. The fix is present in the latest published 5.0.7-SNAPSHOT (build 20, 5.0.7-20260630.144435-20), which is the artifact this PR resolves and the same one CI will resolve - so CI should compile green too, no mavenLocal / GRAILS_INCLUDE_MAVEN_LOCAL dance required anymore.

Verified locally against the published snapshot:

./gradlew :grails-data-graphql-core:compileGroovy --refresh-dependencies

ran the task fresh (not from cache) and BUILD SUCCESSFUL. The previously failing Cannot find matching method ...#withDelegate(Closure, Object) STC error is gone with the workaround removed.

Change. Dropped the inlined ExecutesClosures.withDelegate bodies from Arguable and ComplexTyped and restored the plain inherited-static withDelegate(closure, (Object) ...) call (the 8.0.x form). Behaviorally identical - withDelegate keeps the null-safe DELEGATE_ONLY logic and the finally-block delegate cleanup. The GROOVY-12106 row has been removed from the workarounds table in the description above.

[jdaugherty]

Once Groovy 5.0.7 releases, I agree this is ready for Grails 8.

[jamesfredley]

Merged latest 8.0.x into this branch and resolved the conflicts, then removed the legacy JLine 2 dependency.

Merge conflict resolution (3 files)

8.0.x had renamed ControllerTagLibTypeCheckingExtension → TagLibraryInvokerTypeCheckingExtension and generalized it from controllers to all tag dispatchers (controllers + taglibs) with a canMakeDynamic() guard, while this branch added the Groovy 5 GROOVY-12041 namespace-dispatch handling. The resolution keeps both:

• TagLibraryInvokerTypeCheckingExtension – takes the 8.0.x rename/generalization (isTagDispatcher, canMakeDynamic()) and layers in this branch's isDynamicNamespaceReceiver() so g.foo(...)-style dispatch still resolves under Groovy 5.
• GrailsASTUtils – keeps both the new GRAILS_COMPILE_STATIC_EXTENSIONS list and the ZERO_PARAMETERS deprecation.
• TagLibraryInvokerTypeCheckingExtensionSpec – keeps all of 8.0.x's taglib tests plus this branch's Groovy 5 namespace-dispatch test (retargeted to the renamed extension).

Verified: ./gradlew :grails-core:test --tests "org.grails.compiler.TagLibraryInvokerTypeCheckingExtensionSpec" — all 10 specs pass.

Removed the second JLine (JLine 2)

The jline:jline:2.14.6 pin only existed to satisfy Groovy 4's groovy-groovysh. On Groovy 5, groovy-groovysh uses JLine 3, all source already targets the org.jline.* (JLine 3) API, and the full JLine 3 stack now comes in transitively via groovy-groovysh 5.x. So I dropped the jline2 managed dependency from grails-bom and every explicit jline:jline consumer (grails-console runtime + the groovydoc documentation configs). Jansi was not actually duplicated — there's a single jansi version — so nothing changed there.

Verified: :grails-console:build (incl. groovydoc) and :grails-shell-cli:test pass with only JLine 3 on the classpath.

[jamesfredley]

CI fix pushed (2966b3b2d3).

The previous JLine 2 removal turned CI red: dropping the jline:jline:2.14.6 pin exposed an even older jline:jline:2.11 that Spring Boot CLI (spring-boot-cli:4.1.0) drags in transitively. The SBOM license gate rejects it (BSD-4-Clause), which failed :grails-shell-cli:cyclonedxDirectBom (Core Projects / Coverage) and the Forge :grails-cli SBOM (Build Grails Forge / Forge Projects).

Since no source uses the old jline.* API, I excluded jline:jline from every spring-boot-cli declaration - grails-shell-cli, grails-forge/grails-cli, grails-forge/grails-cli-shadow, and grails-data-neo4j/boot-plugin - leaving only the JLine 3 (org.jline) stack on the classpath.

Verified locally:

• :grails-shell-cli:cyclonedxDirectBom and Forge :grails-cli:cyclonedxDirectBom now generate clean SBOMs (only org.jline:jline@3.30.6).
• :grails-shell-cli:test and :grails-console:test pass.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: 2966b3b
▶️ Tests: 43031 executed
⚪️ Checks: 46/46 completed

---

Learn more about TestLens at testlens.app.