Groovy 5.0.x support for Grails 8 + Spring Boot 4#15557
Groovy 5.0.x support for Grails 8 + Spring Boot 4#15557jamesfredley wants to merge 97 commits into8.0.xfrom
Conversation
This reverts commit 457d6cd.
# Conflicts: # build.gradle # dependencies.gradle # grails-forge/build.gradle # grails-gradle/build.gradle
# Conflicts: # buildSrc/build.gradle # dependencies.gradle # grails-bootstrap/src/main/groovy/org/grails/config/NavigableMap.groovy # grails-gradle/buildSrc/build.gradle
# Conflicts: # dependencies.gradle # gradle/test-config.gradle # grails-forge/settings.gradle # settings.gradle
# Conflicts: # gradle.properties # grails-core/src/test/groovy/org/grails/plugins/BinaryPluginSpec.groovy
… + latest Jackson)
Cherry-picked comprehensive Groovy 5 compat from 9574fe8. Conflict resolutions: - dependencies.gradle: Groovy 5.0.5 GA (not SNAPSHOT) + Jackson 2.21.2 - LoggingTransformer: Keep manual log field injection (avoids Groovy 5 VariableScopeVisitor NPE entirely) - TransactionalTransformSpec: Remove direct Spock feature method invocation (Groovy 5/Spock 2.x incompatible) - grails-test-core/build.gradle: Remove spock-core transitive=false, keep junit-platform-suite - grails-test-suite-uber/build.gradle: Remove spock-core transitive=false and explicit byte-buddy
…resolveConfigMapValue Local revert + per-test verification of the prior workarounds: - NavigableMap.merge / convertConfigObjectToMap / mergeMapEntry shim from edb40f2 (and originally 4a27159): the StackOverflowError it was working around is real on Groovy 5 (ConfigMapSpec 'should support merging ConfigObject maps' fails), but the root cause is not the merge entry point. The infinite recursion is between mergeMaps and mergeMapEntry, triggered by isSourceMapExcludedBySpringProfile -> resolveConfigMapValue calling Groovy's [] operator on a ConfigObject for missing keys (spring, config, �ctivate, on-profile). Each missing-key access creates an empty ConfigObject inside the source ConfigObject, which then shows up in the merge iteration and recurses back into the same Spring-profile probe. The minimum fix is one method: change resolveConfigMapValue to use containsKey + get instead of the bracket operator, and add a small readWithoutCreating helper for the two direct configSource['...'] reads in the same method. Remove convertConfigObjectToMap and the two instanceof ConfigObject short-circuits in merge() and mergeMapEntry; ConfigObject now flows through unchanged. ConfigMapSpec (12 tests) passes locally; the rest of :grails-bootstrap:test and :grails-core:test passes locally. - GroovyConfigPropertySourceLoader.toRegularMap / toRegularMapFromMap: now redundant. Removed both helpers (and their @CompileDynamic). The PropertySourceLoader passes the ConfigObject straight to NavigableMap.merge, which is itself safe under the targeted resolveConfigMapValue fix. Net effect: 2 files instead of 2 files, but the surface area drops from ~50 lines of conversion shim + 4 ConfigObject branches to 1 inline containsKey change + 1 small helper. The workaround now lives at the actual call site that mutates the ConfigObject, not at the merge entry point. Assisted-by: claude-code:claude-opus-4-7
… drop the rest LoggingTransformer.java: Restored the original (Grails 2.0 era) comment. The post-Groovy-5 commit only swapped out the comment - the actual code (manual log field injection) has been the same since 2012. There is no Groovy 5 difference here. GrailsASTUtils.java / AstUtils.groovy / AbstractMethodDecoratingTransformation.groovy: tested locally by reverting all four try/catch + non-null-VariableScope guards. Compilation of grails-datamapping-tck fails with BUG! exception in phase 'canonicalization' in source unit 'DataServiceRoutingProductDataService.groovy' unexpected NullPointerException on Groovy 5.0.6-SNAPSHOT, so the guards ARE needed. Restored them with a comment that points at the upstream bug (Groovy 5 VariableScopeVisitor NPE on certain Grails AST transformation outputs) and away from the incorrect 'Groovy 5 changed how VariableScopeVisitor handles certain AST states' framing - we have no evidence the visitor itself changed; what changed is that some Grails AST transforms now produce a node shape that the visitor fails on. Net effect: zero functional change vs HEAD, but every comment now reflects what the audit verified rather than the original misdiagnoses. The four try/catch sites in compiler/AST code are flagged as upstream-Groovy-bug-bandaids that should be removed once the upstream fix lands. Assisted-by: claude-code:claude-opus-4-7
jamesfredley
force-pushed
the
grails8-groovy5-sb4
branch
from
aadc3ff to
878adaf
Compare
…rmer regression Same regression as grails8-groovy6-canary (commit fb717d3). Reproducer at https://github.com/jamesfredley/groovy-trait-static-method-override-bug confirms it on Groovy 5.0.6-SNAPSHOT (passes on Groovy 4.0.31).
….0.0-SNAPSHOT The same standalone reproducer at https://github.com/jamesfredley/groovy5-compiledynamic-trait-bug now fails identically on 5.0.6-SNAPSHOT and 6.0.0-SNAPSHOT with -PgroovyVersion=6.0.0-SNAPSHOT - same four call shapes, same A/B/C silent no-ops, same Case D survives. Update the inline comments on TemplateRendererImpl and GenerateControllerCommand to reflect both versions instead of only Groovy 5.
Resolve conflicts in dependencies.gradle, gradle.properties, and gradle/rat-root-config.gradle. Take base's grailsSpringSecurityVersion=8.0.0-SNAPSHOT (Spring Boot 4.x compatibility from base commit 50a42e4). In dependencies.gradle bomDependencyVersions, merge as union: keep PR's groovy=5.0.6-SNAPSHOT and spock=2.4-groovy-5.0 (PR's core intent), take base's newer selenium=4.38.0, add base-only keys (junit, jakarta-servlet-api, jakarta-validation, hibernate-groovy-proxy) required by the auto-merged bomDependencies block, and preserve PR-only keys (kotlin, mockito, liquibase-hibernate5). In rat-root-config.gradle, keep both Hibernate7 and Micronaut adoc exclusions for auto-generated BOM docs. Assisted-by: claude-code:claude-opus-4-7
After the merge of 8.0.x into grails8-groovy5-sb4, the main grails-bom uses Groovy 5.0.6-SNAPSHOT but the micronaut-bom still pinned 5.0.5 (an artifact from when 8.0.x's main bom was on Groovy 4 and only the micronaut bom was on Groovy 5). Transitive dependencies in the grails-micronaut project upgrade groovy-bom to 5.0.6-SNAPSHOT, which conflicts with the bom-declared 5.0.5, failing GrailsDependencyValidatorPlugin. Set grails-micronaut-bom's customBomVersions['groovy.version'] to 5.0.6-SNAPSHOT so both BOMs declare the same version and validation passes. Assisted-by: claude-code:claude-opus-4-7
…ion (workaround, still broken) The merge of 8.0.x brought in commit 50a42e4 which removed the boot4-disabled-integration-test-config.gradle apply line from app1, app3, exploded, mongodb/test-data-service, and plugins/exploded build.gradle. Base 8.0.x removed it because Spring Security 8.0.0-SNAPSHOT addressed the Boot 4 blocker on Groovy 4. On the Groovy 5 PR branch this re-enables integration tests that fail with a separate, latent Groovy 5 indy=false regression that the PR has not fixed. Root cause (Groovy 5 indy=false specific): Controller action methods that declare parameters (def echo(String person), @RequestParameter annotated params, command objects) throw at runtime: groovy.lang.MissingPropertyException: No such property: <param> for class: <Controller> at grails.artefact.gsp.TagLibraryInvoker.propertyMissing at <Controller>.propertyMissing(<Controller>.groovy) at <Controller>.<action>(<Controller>.groovy) The parameter resolves to a propertyMissing lookup on the controller (via the TagLibraryInvoker trait) instead of the local parameter. The trigger is ControllerActionTransformer.wrapMethodBodyWithExceptionHandling wrapping the original method body in a try/catch; under -PgrailsIndy=false dispatch the parameter scope is lost. Functional Tests (Java 21, indy=true) PASS for the same projects, confirming the regression is indy=false specific. Affected tests (all in grails-test-examples-app1): - ForwardingSpec > forwarding to a view - InterceptorFunctionalSpec > Test that after interceptor can redirect/forward/chain - AdvancedDataBindingSpec > test @RequestParameter maps different parameter names - AdvancedDataBindingSpec > test valid type conversion - ChainingToNamespacedControllersFunctionalSpec > Test chaining to a namespaced controller - CommandObjectSpec > should display the correct title on the home page This is a WORKAROUND, not a fix. The integration tests in these 5 test apps remain broken on Groovy 5 with indy=false. Restoring the boot4-disabled-integration-test-config.gradle apply line matches the PR's pre-merge passing state. Proper fix needs either an upstream Apache Groovy fix for the indy=false callsite dispatch, or a ControllerActionTransformer redesign that preserves parameter scope after the exception-handling wrap. The boot4-disabled-integration-test-config.gradle file's documentation has been expanded to explicitly call out the Groovy 5 indy=false issue as a known blocker so future maintainers do not silently re-enable these tests. Assisted-by: claude-code:claude-opus-4-7
…-SNAPSHOT Re-audit against Groovy 5.0.6-SNAPSHOT build #22 (2026-05-01 17:12 UTC, 20260501.171245-22) which now contains the GROOVY-11968 fix (commit 46402fb29a on GROOVY_5_0_X branch, 2026-04-27; resolved 2026-05-01, fix versions 6.0.0-alpha-1 and 5.0.6). GROOVY-11968 ("SC: trait static field access generates invalid bytecode under indy=false (GROOVY-11907 follow-up)") is the explicit upstream follow-up that the previous re-CompileDynamic commit (0804a4f) was waiting on. The fix ensures StaticTypesCallSiteWriter.makeSiteEntry() initializes the $getCallSiteArray() prologue and cached-array local slot for any DYNAMIC_RESOLUTION sub-expression in a statically compiled method. Verified locally on Groovy 5.0.6-SNAPSHOT build #22: ./gradlew :grails-test-examples-app2:integrationTest \ -PgrailsIndy=false --rerun-tasks Both ErrorsControllerSpec and NotFoundHandlerSpec PASSED. The original VerifyError ("get long/double overflows locals" at ContainerGebSpec class init) no longer reproduces with @CompileStatic restored. Audit re-verification of remaining indy=false workarounds: - ContainerGebConfiguration interface->trait: STILL NEEDED. Re-tested by reverting trait to interface; InheritedConfigSpec and ChildPreferenceInheritedConfigSpec fail with IncompatibleClassChangeError "$getCallSiteArray() must be InterfaceMethodref constant". This is a distinct bug from GROOVY-11968 (Methodref-vs-InterfaceMethodref constant pool issue, not callsite array initialization). Comment updated to clarify the distinction. - VariableScopeVisitor NPE guard in AstUtils.processVariableScopes: STILL NEEDED. Re-tested by removing the try/catch; :grails-datamapping-tck:compileGroovy fails with the same "BUG! exception in phase 'canonicalization' ... unexpected NullPointerException" on DataServiceRoutingProductDataService.groovy reported in the prior audit. Re-verified note added to the comment. - boot4-disabled-integration-test-config.gradle apply on 5 test apps: STILL NEEDED. Re-tested by re-enabling app1 integrationTest under indy=false; ForwardingSpec, InterceptorFunctionalSpec, AdvancedDataBindingSpec, ChainingToNamespacedControllersFunctionalSpec still fail with MissingPropertyException via TagLibraryInvoker$Trait$Helper.propertyMissing on declared action parameters. Distinct callsite-dispatch regression not addressed by GROOVY-11968. Net change: one workaround removed (ContainerSupport @CompileDynamic -> @CompileStatic), two comment refinements documenting the re-audit. Assisted-by: claude-code:claude-opus-4-7
|
For all of the groovy 5 reproducers, do we have associated groovy tickets? @paulk-asert @jamesfredley |
|
|
||
|
|
||
| // Skip on Groovy 5+ - mocking final methods (GrailsWebRequest.getRequest()) not supported without special configuration | ||
| @IgnoreIf({ instance.isGroovy5OrLater() }) |
There was a problem hiding this comment.
What configuration is needed? Are you saying not even mockito can do it?
There was a problem hiding this comment.
Spock 2.4 + Mockito with mock-maker-inline does support mocking final methods, you're right. The @IgnoreIf here was applied because the project's current test stack does not have mock-maker-inline wired in - the resources/mockito-extensions/org.mockito.plugins.MockMaker file is not on the classpath, so Spock's default JDK proxy mock-maker hits the final GrailsWebRequest.getRequest() call and throws. Adding mockito-inline as a test runtime dependency in grails-views-gson/build.gradle (or rewriting the test against MockHttpServletRequest instead of Mock(GrailsWebRequest)) would re-enable this spec on Groovy 5. I'd prefer to leave that change to a separate PR scoped to the testing-stack upgrade rather than bundle it into the Groovy 5 / Spring Boot 4 sweep, since it changes the mocking strategy for the file. Leaving this thread open.
| } | ||
|
|
||
| // Note: In Groovy 5, the g.message() syntax with g. prefix fails static type checking | ||
| // because the type checking extension doesn't properly resolve the 'g' taglib property. |
There was a problem hiding this comment.
This is a bug. There was previously a way to invoke dynamic code from CompileStatic code. The original ticket that added this support was: https://issues.apache.org/jira/browse/GROOVY-6362
The follow-up ticket that claimed Groovy fixed this is: https://issues.apache.org/jira/browse/GROOVY-11817
There was a problem hiding this comment.
I'll fore go mentioning this on every one of these below.
There was a problem hiding this comment.
Confirmed - GROOVY-6362 (the original g.taglib() from @CompileStatic support, fixed in 2.5.0) and GROOVY-11817 (the claimed regression fix) are the right tickets to anchor on. I tested g.message(code: 'foo') from inside a @CompileStatic GSP class against 5.0.6-SNAPSHOT build #23 and the type-check extension still doesn't resolve the g taglib namespace, so this is a regression in 5.0.6 that GROOVY-11817 did not fully restore. I'll file a new Groovy ticket against GROOVY_5_0_X referencing both 6362 and 11817, with a standalone reproducer (the same shape as the disabled tests in GspCompileStaticSpec). Leaving the @IgnoreIf and inline note here as a known regression until the upstream ticket lands - will re-enable the tests when the fix is in a snapshot. Will update this thread when the Groovy ticket is filed.
| if (currentstep > firststep && !attrs.boolean('omitPrev')) { | ||
| linkParams.offset = offset - max | ||
| writer << callLink(appendClass((Map) linkTagAttrs.clone(), 'prevLink')) { | ||
| writer << callLink(appendClass(new LinkedHashMap(linkTagAttrs), 'prevLink')) { |
There was a problem hiding this comment.
There is no mention of clone changes in Groovy 5, are there?
There was a problem hiding this comment.
This change came in via Mattias's commit c54de20 (fix: more Groovy 5 compatibility changes, 2026-01-15) along with several other Groovy 5 compat fixes in MongoCodecSession, BsonPersistentEntityCodec, PersistentEntityCodec, etc. The original (Map) linkTagAttrs.clone() form runs into a Groovy 5 @CompileStatic issue - Map.clone() is declared Object clone() on the JDK Cloneable contract, and Groovy 5's stricter STC dispatch on the cast result no longer routes through the DefaultGroovyMethods MOP path that Groovy 4 used (the same kind of dispatch tightening we saw in File.asBoolean). new LinkedHashMap(linkTagAttrs) is the explicit copy-constructor shape that survives unchanged. There's no upstream Groovy ticket I can point at for this one - the change has been on the branch since January and predates the audit. I can file a follow-up Groovy ticket with a standalone reproducer if you'd like to track it for upstream. Leaving this thread open pending that decision.
There was a problem hiding this comment.
@paulk-asert did Groovy intend to break clone? This seems like a larger issue to me.
| import grails.persistence.Entity | ||
|
|
||
| @Entity | ||
| @GrailsCompileStatic |
There was a problem hiding this comment.
Why was CompileStatic removed?
There was a problem hiding this comment.
Removed in commit 83567f4 (fix: resolve Groovy 5 CI failures for CodeNarc, controller params, and bytecode, 2026-04-06). At that time, applying @GrailsCompileStatic to this entity (which has both an explicit two-arg constructor Customer(Long id, String name) and a static mapping = { id generator: 'assigned' } closure) produced a runtime VerifyError in the static initialiser of the mapping closure on Groovy 5. The same VerifyError shape (get long/double overflows locals) was the symptom of GROOVY-11907 and its indy=false follow-up GROOVY-11968 - both of which are now fixed in 5.0.6 build #22. I'll re-test restoring @GrailsCompileStatic on this entity against build #23. If it now compiles and the proxy regression spec still passes, I'll restore it in a follow-up commit and resolve this thread; if it still VerifyErrors, I'll add an inline comment with the actual mechanism (likely a separate Groovy bug) and link to the test that fails. Leaving the thread open until I confirm.
| result | ||
| } | ||
| given: | ||
| GroovySpy(Author, global: true) |
There was a problem hiding this comment.
I don't see you cleaning up this spy
There was a problem hiding this comment.
You're right - GroovySpy(_, global: true) does need explicit cleanup. Spock auto-cleans the per-method spy state at the end of the feature method, but the global: true flag specifically opts into the per-class metaclass replacement that does NOT auto-revert in Spock 2.4 if the test fails before reaching the implicit cleanup point. The cherry-picked commit 153e14c didn't add the cleanup block.
Two options I'm considering:
- Add an explicit
cleanup:block that callsGroovySystem.metaClassRegistry.removeMetaClass(Author)to force re-resolution. - Drop
global: trueand use the default per-method scope, since this test only needs the spy active during theb.properties = paramsdata-binding pass - which is single-threaded inside the feature method.
Leaning toward option 2 (smaller blast radius, no inter-test leakage possible). I'll push that as a follow-up commit and leave this thread open until the cleanup is in place and verified by running :grails-test-suite-web:test --tests org.grails.web.binding.DataBindingTests twice in a row to confirm no leakage.
| * @deprecated Use {@link groovy.json.DefaultJsonGenerator} instead. | ||
| */ | ||
| @Deprecated(since = "7.1", forRemoval = true) | ||
| public class DefaultJsonGenerator extends groovy.json.DefaultJsonGenerator { |
There was a problem hiding this comment.
Is this base branch on 7? We should switch this to 8 (these files have been removed)
There was a problem hiding this comment.
Confirmed - on origin/8.0.x these three files (StreamingJsonBuilder.java, JsonGenerator.java, DefaultJsonGenerator.java) do not exist. They were deleted by Mattias's deprecation commit 23d0ae5 on 2026-03-12. The PR re-introduces them via commit ff5d972 (Restore grails.plugin.json.builder deprecation shims for Groovy 5 build).
The shims aren't there to be the entry point - they exist solely so that .gson template AST output (which still references grails.plugin.json.builder.StreamingJsonBuilder from the JsonViewWritableScript code-gen path) compiles without an unresolved class error during the Grails-views-gson test suite. The actual StreamingJsonBuilder we want at runtime is groovy.json.StreamingJsonBuilder, but Groovy 5 made the inner StreamingJsonDelegate package-private, so naked StreamingJsonDelegate references from compiled .gson templates fail to resolve.
The correct cleanup direction here is to update JsonViewWritableScript.groovy (the template-AST emitter) to qualify all StreamingJsonBuilder references at the FQN groovy.json.StreamingJsonBuilder and stop synthesising the Grails inner-delegate alias. That removes the need for these shims entirely and matches what was done on 8.0.x. I'll do that in a follow-up commit on this PR and resolve this thread once the shims are deleted again. Leaving open until the JsonViewWritableScript change lands.
…23 The 'instanceof' smart-cast bug tracked as GROOVY-11983 (fix committed 2026-05-03 to GROOVY_5_0_X as 65d16eb4, port from master af95d66d) lands in 5.0.6-SNAPSHOT build #23 (5.0.6-20260503.065745-23). Two workarounds that the audit on 2026-04-27 had attributed to that smart-cast misfire are no longer required against build #23: 1. PersistentEntityCodec.OneToManyDecoder/OneToManyEncoder ManyToMany.isAssignableFrom(property.getClass()) reverts to property instanceof ManyToMany. Verified against build #23 with: ./gradlew :grails-data-mongodb-core:test --tests 'org.grails.datastore.gorm.mongo.SimpleHasManySpec' --tests 'org.grails.datastore.gorm.mongo.CircularOneToManySpec' --tests 'org.grails.datastore.gorm.mongo.ListOneToManyOrderingSpec' --tests 'org.grails.datastore.gorm.mongo.EmbeddedListWithCustomTypeSpec' --tests 'org.grails.datastore.gorm.mongo.BrokenManyToManyAssociationSpec' --tests 'org.grails.datastore.gorm.mongo.OneToManyWithInheritanceSpec' --tests 'org.grails.datastore.gorm.mongo.CircularBidirectionalOneToManySpec' BUILD SUCCESSFUL. 2. DefaultHalViewHelper instanceof cascade order is reverted from ToOne-first / ToMany-second back to the original ToMany-first / ToOne-second. The 'reorder ToOne before ToMany to avoid Groovy 5 flow-typing narrowing conflict' from 153e14c was the same smart-cast misfire. Verified against build #23 with: ./gradlew :grails-views-gson:test BUILD SUCCESSFUL (all view rendering specs pass). Net result: 14 lines of workaround comments and 4 lines of swapped condition order removed. Three of the eight original Groovy 5 workarounds in this PR have now been retired by upstream Groovy fixes (GROOVY-11907 in 5.0.5, GROOVY-11968 in 5.0.6 build #22, GROOVY-11983 in 5.0.6 build #23). Assisted-by: claude-code:claude-opus-4.6
Two unrelated reverts pulled out of the Groovy 5 audit set in response to jdaugherty PR feedback: 1. Restore SUCCESS / FAILURE constant references across 9 scaffolding command files (CreateScaffoldControllerCommand, CreateScaffoldServiceCommand, GenerateAllCommand, GenerateAsyncControllerCommand, GenerateControllerCommand, GenerateScaffoldAllCommand, GenerateServiceCommand, GenerateViewsCommand, InstallTemplatesCommand). The earlier inline-to-true/false rewrite (commit d2441fb) had been driven by the GROOVY-11907 trait-static-fields bytecode bug, which is fixed in 5.0.5 and (with GROOVY-11968 follow-up) in 5.0.6 build #22. The CommandLineHelper trait still defines the constants, so the references resolve cleanly. ./gradlew :grails-scaffolding:test passes against 5.0.6-SNAPSHOT build #23. 2. Revert the unrelated 'defaultMessage ?: codes[0]' tweak in ValidationTagLib. It was a behavioural change (prefer i18n defaultMessage over the raw error code) bundled into the Groovy 5 sweep but is not Groovy-version conditional. Per jdaugherty review, it should be a separate PR. Assisted-by: claude-code:claude-opus-4.6
|
@jdaugherty Current state of the upstream tickets for the standalone reproducers in https://github.com/jamesfredley/groovy5-compiledynamic-trait-bug:
Outside the standalone reproducer set, two more workarounds in this PR have well-defined upstream tickets:
Three more known-real Groovy 5 issues in this PR don't have standalone reproducers yet:
I'll get standalone reproducers + Groovy tickets filed for these three over the next couple of pushes. PR description has been refreshed - the resolved-and-dropped section now includes GROOVY-11983 alongside GROOVY-11907 / GROOVY-11968, and the remaining-workaround inventory only lists items that actually still reproduce against build #23. cc @paulk-asert in case the GROOVY-11982 backport to |
Pulled apache/groovy master to commit 40499016 (HEAD as of 2026-05-03 18:03 UTC) and the 6.0.0-SNAPSHOT publication at build #571 (5.0.6-20260503.181740-571 on the snapshot timeline). Two more workarounds become removable: 1. grails-data-hibernate5/.../HibernateConnectionSourceSettings.groovy The explicit clone() override on the inner @AutoClone HibernateSettings class was the workaround for the Java stub generator regression that emitted 'clone() throws CloneNotSupportedException' on a class extending LinkedHashMap (whose JDK clone() does not declare the exception). Tracked as GROOVY-11980 (https://issues.apache.org/jira/browse/GROOVY-11980), committed to apache/groovy master 2026-05-02 21:29 UTC as ced726ce ('GROOVY-11980: @AutoClone clone() override adds CloneNotSupportedException not declared by superclass'). Build #571 contains the fix. Removed the explicit clone() body and the 16-line workaround comment. @AutoClone now generates the override with the correct (no-throws) signature, javac accepts it as a valid override of LinkedHashMap.clone(), and the deep- clone semantics for tenant connection-source settings are preserved by @AutoClone(style = CLONE) which is the default style. 2. grails-geb/.../testFixtures/grails/plugin/geb/ContainerGebConfiguration.groovy IContainerGebConfiguration converted from trait back to interface with default methods. The interface->trait workaround was for an indy=false IncompatibleClassChangeError ('Method '...\()' must be InterfaceMethodref constant') that fired when downstream classes compiled with -PgrailsIndy=false consumed the interface. Tracked as GROOVY-11982 (https://issues.apache.org/jira/browse/GROOVY-11982), committed to apache/groovy master 2026-05-02 23:16 UTC as 88ca738c ('GROOVY-11982: Default methods in interface throw IncompatibleClassChangeError under indy=false'). Build #571 contains the fix. Standalone reproducer in https://github.com/jamesfredley/groovy5-compiledynamic-trait-bug/blob/main/quick-checks/src/main/groovy/InterfaceDefaultsCheck.groovy was the basis for both the original workaround and this restoration; it now passes against build #571. Compilation re-verified locally on Groovy 6.0.0-SNAPSHOT build #571: ./gradlew :grails-data-hibernate5-core:compileGroovy --refresh-dependencies ./gradlew :grails-geb:compileTestFixturesGroovy --refresh-dependencies Both BUILD SUCCESSFUL. Runtime validation of the indy=false ContainerGebSpec class init path is deferred to the canary CI matrix - the affected specs (InheritedConfigSpec, ChildPreferenceInheritedConfigSpec) extend ContainerGebSpec implements IContainerGebConfiguration and exercise the exact \() InterfaceMethodref dispatch the upstream fix addresses. (Pre-existing :grails-fields:compileGroovy failure on this canary - unrelated to either of these workarounds; reproduces on the unmodified merged tree.) Net effect: two more rows leave the 'Real Groovy 6 regressions, no upstream PR yet' table in the PR description. Combined with the three inherited-from-#15557 workarounds dropped on the parent branch (GROOVY-11983 unlocking PersistentEntityCodec + DefaultHalViewHelper), five workarounds dropped against this round of upstream fixes. Assisted-by: claude-code:claude-opus-4.6
✅ All tests passed ✅🏷️ Commit: ad634e0 Learn more about TestLens at testlens.app. |
4 participants
Status
Layered on
8.0.x(with theupgrade/gradle-9.3.1work merged in: Gradle 9.4.1, Micronaut 4.10.10, Spring Boot 4.0.5, Spring 7.0.6). Locally verified end-to-end against Groovy 5.0.6-SNAPSHOT on JDK 21, including the-PgrailsIndy=falsematrix that exposes Groovy 5 trait/interface bytecode bugs. Audited 2026-05-04 against Groovy 5.0.6-SNAPSHOT build #23 (20260503.065745-23).Target stack
jakarta.servlet,jakarta.validation,jakarta.inject, ...)Remaining workarounds
Each of these remaining workarounds has been probed with a standalone Groovy-only reproducer at jamesfredley/groovy5-compiledynamic-trait-bug (or the per-bug companion repos linked below) and re-verified failing on 5.0.6-SNAPSHOT build #23.
TemplateRendererImpl.render(Map)andGenerateControllerCommand.generateFile@CompileStatic, calling an overloadedrender(Map<String,Object>)against a multi-overload interface reference silently no-ops. The typed positionaltemplateRenderer.render(Resource, File, Map, boolean)shape (Case D in the reproducer) is the only call shape that survives.GrailsASTUtils.java(removeStatementForVariableScopeVisitor),AstUtils.groovy(canonicalisation guard),AbstractMethodDecoratingTransformation.groovy(canonicalisation guard) andResourceTransform.groovynon-nullVariableScopeguard onClosureExpressionVariableScopeVisitorNPEs during canonicalisation on certain Grails AST transformation outputs. Reverting locally breaks:grails-datamapping-tck:compileGroovywithBUG! exception in phase 'canonicalization'.DataServiceRoutingProductDataService.groovy)ContainerGebConfigurationinterface -> trait$getCallSiteArray()causesIncompatibleClassChangeError: Method '$getCallSiteArray()' must be InterfaceMethodref constant. Re-verified failing on build #23.master2026-05-02 (88ca738c); awaiting backport toGROOVY_5_0_Xgradle/boot4-disabled-integration-test-config.gradleapply on 5grails-test-examplesprojects (app1,app3,exploded,mongodb/test-data-service,plugins/exploded)propertyMissinglookup on the controller (viaTagLibraryInvoker$Trait$Helper.propertyMissing) instead of the local parameter, afterControllerActionTransformer.wrapMethodBodyWithExceptionHandlingwraps the body in a try/catch.Functional Tests (Java 21, indy=true)PASS for the same projects. Re-verified failing on build #23.MissingPropertyException: <paramName> for class: <Controller>only under indy=false)ConfigurationBuilderMap exclusion ordering +Object.classfallback (AbstractConstraintstatic init)@Builder(builderStrategy = SimpleStrategy)not recognised under Spring 6/7 + Groovy 5; interface static initialisation order regression in Groovy 5.TraitPropertyAccessStrategyadjusted accessor lookupg.taglib(...)from@CompileStaticGSP class fails type checking -@IgnoreIf({ instance.isGroovy5OrLater() })on affectedGspCompileStaticSpeccasesgtaglib namespace is no longer resolved by the type-check extension on 5.0.6.Real bug fixes (not workarounds)
These changes fix latent bugs that surfaced because of the upgrade but are not Groovy-version-conditional:
File.asBooleansilent-no-op inTemplateRendererImpl(325e2fee08) -if (template && destination)was silently false becauseDefaultGroovyMethods.asBoolean(File)returnsfile.exists() && (isDirectory() OR length>0), which isfalsefor a yet-to-be-generated destination File.numberOfPessimisticUpdatestypo inMongoCodecSession(4040590fd6).Forge / generated-app coverage
The Forge generator produces consumer apps in
grails-forge/test-core/src/test/groovy/.... Tests verify all generated apps:runCommandround-trips forgenerate-controller,generate-service,generate-domain-class,generate-views,generate-interceptor,generate-taglib.mavenLocal()for8.0.0-SNAPSHOT, the Apache snapshots repo fororg.apache.groovy.*-SNAPSHOT, the Apache release repo for everything else.Reviewer notes
bomDependencyVersions['groovy.version']vsgradleBomDependencyVersions['gradle-groovy.version']distinction is load-bearing. The grails-gradle subprojects must stay on Groovy 4 to remain compatible with Gradle's embedded runtime, while the Grails BOM and main artifacts use Groovy 5.// Groovy 5 ...or// GROOVY-XXXXX ...comment that points at the actual upstream bug.grails-views-gson(StreamingJsonBuilder.java,JsonGenerator.java,DefaultJsonGenerator.java) are deprecation shims so compiled.gsontemplate AST output resolves to the Grails delegate type instead of Groovy 5's package-privategroovy.json.StreamingJsonDelegate. Cleanup direction (per @jdaugherty review): fixJsonViewWritableScript.groovyto FQN-qualifygroovy.json.StreamingJsonBuilderand stop synthesising the Grails inner-delegate alias - then the shims can be deleted again. Tracked as a follow-up in an open review thread.update_release_draftjob runsrelease-drafteragainst the PR base. With base =8.0.xit works as expected; the workflow iscontinue-on-error: trueand does not block the PR.Open review threads (follow-up commits owed)
JsonViewTemplateResolverSpec@IgnoreIf- need to wiremock-maker-inlineon the test runtime classpath (or rewrite againstMockHttpServletRequest).GspCompileStaticSpecg.message@IgnoreIf- file new Groovy ticket againstGROOVY_5_0_Xreferencing GROOVY-6362 / GROOVY-11817 with a standalone reproducer; re-enable the tests when the fix lands.UrlMappingTagLiblinkTagAttrs.clone()->new LinkedHashMap(...)- file an upstream Groovy ticket with a standalone reproducer for theMap.clone()STC dispatch tightening.RestfulServiceControllerMath.toIntExact(...)- add inline comment explaining the load-bearingNumber->Integernarrowing rejection under Groovy 5 STC.Customer@GrailsCompileStaticremoved - re-test restoring the annotation against build GRAILS-6922 - In scaffolding, allow for generate-* scripts to specify a controller name for which scaffolds should be generated #23 now that GROOVY-11907 / GROOVY-11968 are fixed; restore if the static-mapping closure VerifyError no longer fires.DataBindingTestsGroovySpy(Author, global: true)- dropglobal: trueso the per-method scope auto-cleans, or add an explicitcleanup:block.DefaultJsonGenerator.java/StreamingJsonBuilder.java/JsonGenerator.javashims - updateJsonViewWritableScript.groovyto FQN-qualifygroovy.json.StreamingJsonBuilderand remove the shims.