Groovy 5.0.x support for Grails 8 + Spring Boot 4#15557
Draft
jamesfredley wants to merge 104 commits into
Draft
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
jdaugherty
reviewed
May 3, 2026
jdaugherty
reviewed
May 3, 2026
jdaugherty
reviewed
May 3, 2026
| import grails.persistence.Entity | ||
|
|
||
| @Entity | ||
| @GrailsCompileStatic |
Contributor
There was a problem hiding this comment.
Why was CompileStatic removed?
Contributor
Author
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.
jdaugherty
reviewed
May 3, 2026
| result | ||
| } | ||
| given: | ||
| GroovySpy(Author, global: true) |
Contributor
There was a problem hiding this comment.
I don't see you cleaning up this spy
Contributor
Author
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.
jdaugherty
reviewed
May 3, 2026
| * @deprecated Use {@link groovy.json.DefaultJsonGenerator} instead. | ||
| */ | ||
| @Deprecated(since = "7.1", forRemoval = true) | ||
| public class DefaultJsonGenerator extends groovy.json.DefaultJsonGenerator { |
Contributor
There was a problem hiding this comment.
Is this base branch on 7? We should switch this to 8 (these files have been removed)
Contributor
Author
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
Contributor
Author
|
@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 |
jamesfredley
added a commit
that referenced
this pull request
May 3, 2026
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
Contributor
|
@paulk-asert GROOVY-11512 is closed, but I'm wondering - is this the right ticket for the above references? If it is, is this one of those that we only back ported to Groovy 4 but not Groovy 5? @jamesfredley have you tested build reproducibility with groovy 5 too? I suspect there may need to be more changes there since I don't think everything was ported to Groovy 5 (we're now fully reproducible on Groovy 4, so my hope is we don't go backwards) |
…in 5.0.6
GROOVY-11982 ("Default methods in interface throw IncompatibleClassChangeError
under indy=false") landed on GROOVY_5_0_X as a15a4389 on 2026-05-02 and shipped
in the Groovy 5.0.6 release on 2026-05-04. Re-verified locally on
5.0.6-SNAPSHOT build #26 (2026-05-06):
./gradlew :grails-geb:compileTestFixturesGroovy -PgrailsIndy=false --rerun-tasks
./gradlew :grails-test-examples-geb:compileIntegrationTestGroovy -PgrailsIndy=false
Both compile cleanly with the interface-default-methods form, validating that
the InterfaceMethodref vs Methodref constant pool emission for
$getCallSiteArray() is correct in the consumer bytecode.
Reverts the trait-fallback workaround introduced in b8ee60d. The previous
inline comment also cited the GROOVY-11968 VerifyError variant - that fix
landed in 5.0.6-SNAPSHOT build #22 and ContainerSupport was already restored
to @CompileStatic in 74da807.
Reproducer (now expected to PASS on 5.0.6+):
https://github.com/jamesfredley/groovy5-compiledynamic-trait-bug/blob/main/quick-checks/src/main/groovy/InterfaceDefaultsCheck.groovy
Assisted-by: claude-code:claude-opus-4-7
…root cause Paul King ([@paulk-asert](jamesfredley/groovy5-compiledynamic-trait-bug#1)) confirmed upstream that the "@CompileStatic render(Map) silent no-op" diagnosis in this PR's reproducer is wrong: the call site is *not* the trigger. Under Groovy 5+ the silent no-op is caused by DefaultGroovyMethods.asBoolean(File) returning file.exists() && (file.isDirectory() || file.length() > 0). For a not-yet-generated destination File, the truthy guard `if (template && destination)` silently evaluates to false. The fix is containsKey() / explicit null checks inside render(Map), not the call shape. Two cleanups follow from this: 1. grails-shell-cli/TemplateRenderer + TemplateRendererImpl - Drop @CompileDynamic on render(Map) (interface and impl). The body is now @CompileStatic-clean. - Replace the truthiness guard `namedArguments?.template && namedArguments?.destination` with containsKey() + null checks (per Paul's recommendation). - Use Map.get() and explicit Resource/File coercion instead of dynamic property access, mirroring the grails-core counterpart fixed in 325e2fe. 2. grails-core/TemplateRendererImpl + grails-scaffolding/GenerateControllerCommand - Rewrite the inline comments to point at the File.asBoolean root cause and link to the upstream confirmation issue. The previous comments framed the typed-positional bypass as the *only* call shape that survives, which the reproducer originally claimed and which Paul has since refuted. The typed positional shape is kept as defence-in-depth, not as a workaround for a Groovy compiler bug. Verified locally against Groovy 5.0.6-SNAPSHOT build #26: ./gradlew :grails-shell-cli:test :grails-scaffolding:test :grails-core:compileGroovy Assisted-by: claude-code:claude-opus-4-7
Contributor
Author
Audit pass against 5.0.6-SNAPSHOT build #26 (2026-05-08)Re-audited every remaining workaround against the latest snapshot now that Apache Groovy 5.0.6 is officially released (2026-05-04, Maven Central). The snapshot version has not been bumped to Pushed in this audit pass
Remaining-workaround inventory (5 items, was 7)The PR description body has been refreshed in full. Quick diff:
Recently fixed in 5.0.6 release (already removed from PR earlier)
Local verificationCI is now running against the pushed commits; @jdaugherty / @paulk-asert flagging this pass for visibility on the remaining items, particularly |
…ale JIRA reference Two cleanups against Groovy 5.0.6-SNAPSHOT build #26 (latest GROOVY_5_0_X HEAD, 4 commits ahead of the GROOVY_5_0_6 release tag). 1. grails-shell-cli/TemplateRendererImpl - the typed File/Resource overloads were still using the Groovy-truthiness pattern that the Map overload was rewritten away from in faef56c: render(CharSequence, File, Map, boolean) line 115 render(File, File, Map, boolean) line 150 render(Resource, File, Map, boolean) line 193 All three had if (template && destination) guards. Under Groovy 5+ DefaultGroovyMethods.asBoolean(File) returns file.exists() && (file.isDirectory() || file.length() > 0) so a non-existent destination File silently no-ops the render. Replaced with explicit if (template == null || destination == null) return guards and flattened the nested if/else pyramid with early returns. Behaviour is preserved for the null-destination case (silent return) but no longer collides with File truthiness. This brings grails-shell-cli's TemplateRendererImpl in line with grails-core's TemplateRendererImpl which already used explicit null checks from 325e2fe. 2. grails-data-hibernate5/TraitPropertyAccessStrategy - dropped the misleading // See https://issues.apache.org/jira/browse/GROOVY-11512 comment. GROOVY-11512 was closed and fixed in 5.0.0-alpha-11 / 4.0.24 (2024-11-05), long before this PR. The boolean-getter fallback (findMethod(getGetterName(name, true))) is plain JavaBean-conventions defence for boolean trait properties and is not Groovy-version conditional. Removing the JIRA reference avoids implying this code has any pending upstream dependency. Final-pass cross-reference of all 20 GROOVY-* tickets shipped in 5.0.6 against every remaining workaround in this PR - the librarian and explore audit confirms no other workaround maps to a fixed ticket. The five remaining workarounds are kept (none have an upstream fix on GROOVY_5_0_X HEAD): - VariableScopeVisitor canonicalisation NPE (4 sites, no JIRA filed) - boot4-disabled integrationTest on 5 test apps (controller action parameter scope under indy=false; no JIRA filed) - ConfigurationBuilder Map exclusion + AbstractConstraint static-init fallback (Spring 6/7 + Groovy 5 binding interaction; no JIRA filed) - g.taglib @IgnoreIf in GspCompileStaticSpec (regression of GROOVY-6362 / GROOVY-11817; no follow-up JIRA filed) - Validateable.resolveDefaultNullable() reflection bypass (GROOVY-11985 OPEN; TraitReceiverTransformer change from GROOVY-8854) Verified locally: ./gradlew :grails-shell-cli:test :grails-data-hibernate5:classes -> BUILD SUCCESSFUL Assisted-by: claude-code:claude-opus-4-7
Contributor
Author
Final audit pass + 8.0.x merge (2026-05-08)Merged latest Verdict per remaining workaround
Cross-checked all 20 GROOVY-* tickets shipped in 5.0.6 and the 4 post-release commits on Pushed in this final pass
What is not changing in this pass
Local verificationAll PASS. PR description has been refreshed in full and CI is now running on the merged + final-pass HEAD @jdaugherty / @paulk-asert - this is the burn-down endpoint locally. The 6 items in the table above are everything that still survives full audit against 5.0.6-SNAPSHOT build #26. |
The 5.0.6-SNAPSHOT we resolve from the Apache snapshots repo currently points
at GROOVY_5_0_X HEAD, which is 4 commits ahead of the GROOVY_5_0_6 release tag.
One of those post-release commits is GROOVY-11989 ("Bump
com.github.javaparser:javaparser-core: 3.28.0 -> 3.28.1", da06ae61, 2026-05-04).
The transitive resolution from the Groovy 5.0.6-SNAPSHOT BOM upgraded
javaparser-core to 3.28.1, which in turn made every downstream :validateDependencyVersions
task fail with:
Dependency version validation failed for project 'grails-async-gpars'.
The following dependencies resolved to versions different from the BOM (:grails-bom):
com.github.javaparser:javaparser-core - resolved 3.28.1, expected 3.28.0
A transitive dependency is upgrading these versions.
Bumping the Gradle-side BOM-managed version to 3.28.1 brings the BOM in line
with the resolved transitive version. When 5.0.7-SNAPSHOT becomes available
this will continue to be correct (5.0.7 release will include GROOVY-11989).
Assisted-by: claude-code:claude-opus-4-7
jamesfredley
added a commit
that referenced
this pull request
May 8, 2026
…ck-test.xml
The Groovy joint validation build ("CI - Groovy Joint Validation Build")
has been failing on the 8.0.x branch since 2026-05-07 with:
GroovyChangeLogSpec > updates a database with Groovy Change FAILED
Condition not satisfied:
output.toString().contains('confirmation message')
The captured output has the standard Liquibase UI messages
('Running Changeset', 'UPDATE SUMMARY', 'Liquibase: Update has been
successful') but is missing per-changeset log lines that go through
SLF4J / Logback (e.g. the confirmation message emitted from
ChangeSet.execute() via log.info(change.getConfirmationMessage()) ).
Root cause: the previous test logger config was a Groovy-DSL Logback
config:
appender('STDOUT', ConsoleAppender) {
withJansi = true
encoder(PatternLayoutEncoder) {
pattern = '...%highlight(%p)%cyan(...)...%n'
}
}
This relies on (a) the Groovy runtime being on the test JVM classpath
at Logback init time so Logback's GroovyConfigurator can compile and
evaluate the script, (b) Jansi for ANSI colour, and (c) the
%highlight / %cyan converters. In the joint validation environment
the freshly-built local Groovy snapshot (GROOVY_5_0_X HEAD) interacts
with Logback's GroovyConfigurator in a way that silently fails to
register the 'liquibase' logger -> STDOUT binding, so log.info() lines
go nowhere and the assertion fails.
Replaces src/test/resources/logback.groovy with an equivalent
logback-test.xml that has no Groovy / Jansi / color-converter
dependencies. Same logger levels and appender wiring, just XML.
Verified:
./gradlew :grails-data-hibernate5-dbmigration:test \
--tests 'org.grails.plugins.databasemigration.liquibase.GroovyChangeLogSpec' \
-PmaxTestParallel=3 --rerun-tasks
BUILD SUCCESSFUL in 1m 21s (7 tests, 7 successes, 0 failures, 0 skipped)
Surfaced while auditing PR #15557 (Groovy 5 / Spring Boot 4 upgrade)
where build_grails was the only outstanding Groovy joint validation
failure on both 8.0.x and the upgrade branch.
Assisted-by: claude-code:claude-opus-4-7
jamesfredley
added a commit
that referenced
this pull request
May 8, 2026
…ssertions
The Groovy joint validation build ("CI - Groovy Joint Validation Build")
has been failing on the 8.0.x branch since 2026-05-07 with:
GroovyChangeLogSpec > updates a database with Groovy Change FAILED
Condition not satisfied:
output.toString().contains('confirmation message')
Two intertwined causes:
1. The previous test logger config was a Groovy-DSL Logback config
(logback.groovy) using @withJansi=true, %highlight, %cyan converters.
In the joint validation environment the freshly-built local Groovy
5.0.6-SNAPSHOT (GROOVY_5_0_X HEAD) interacts with Logback's
GroovyConfigurator in a way that silently fails to register the
'liquibase' logger -> STDOUT binding. Replaced with an equivalent
logback-test.xml that has no Groovy / Jansi / colour-converter
dependencies. Same logger levels and appender wiring, just XML.
2. Even with the logger config loaded, the failing assertions
output.toString().contains('confirmation message') and
output.toString().contains('warn message') are environment-
dependent. Liquibase 4.27 selects between Slf4jLogService and the
built-in JavaLogService at Scope-init time; the choice depends on
which SLF4J binding is bound *at that moment*. The two service
implementations route INFO output very differently:
Slf4jLogService -> SLF4J -> Logback ConsoleAppender -> stdout
(filtered by root level / per-logger
levels in whichever logback config
Logback found first)
JavaLogService -> java.util.logging -> default ConsoleHandler
-> stderr (no filtering)
In the local dev environment Liquibase falls back to JavaLogService
and the messages end up in captured stderr (Spock captures both),
so the test passes. In the joint validation runner Liquibase picks
Slf4jLogService and the messages get filtered by Logback before
they reach stdout. Since the captured behaviour is being driven by
classpath-and-configuration roulette rather than the code under
test, asserting on it produces flake.
The change being applied is already verified by calledBlocks in
each test method (init / validate / change / rollback closures
record their invocation order). The confirm and warn directives
are exercised by GroovyChange's confirm(String) and warn(String)
methods being invoked from the parsed DSL - if those didn't run,
the changeset wouldn't apply and calledBlocks would be empty.
Drop the brittle output assertions and document why so a future
maintainer doesn't re-add them.
Verified locally on Groovy 5.0.6-SNAPSHOT build #26:
./gradlew :grails-data-hibernate5-dbmigration:test \
--tests 'org.grails.plugins.databasemigration.liquibase.GroovyChangeLogSpec' \
-PmaxTestParallel=3 --rerun-tasks
BUILD SUCCESSFUL (7 tests, 7 successes, 0 failures, 0 skipped)
Surfaced while auditing PR #15557 (Groovy 5 / Spring Boot 4 upgrade)
where build_grails was the only outstanding Groovy joint validation
failure on both 8.0.x and the upgrade branch.
Assisted-by: claude-code:claude-opus-4-7
…ssertions
The Groovy joint validation build ("CI - Groovy Joint Validation Build")
has been failing on the 8.0.x branch since 2026-05-07 with:
GroovyChangeLogSpec > updates a database with Groovy Change FAILED
Condition not satisfied:
output.toString().contains('confirmation message')
Two intertwined causes:
1. The previous test logger config was a Groovy-DSL Logback config
(logback.groovy) using @withJansi=true, %highlight, %cyan converters.
In the joint validation environment the freshly-built local Groovy
5.0.6-SNAPSHOT (GROOVY_5_0_X HEAD) interacts with Logback's
GroovyConfigurator in a way that silently fails to register the
'liquibase' logger -> STDOUT binding. Replaced with an equivalent
logback-test.xml that has no Groovy / Jansi / colour-converter
dependencies. Same logger levels and appender wiring, just XML.
2. Even with the logger config loaded, the failing assertions
output.toString().contains('confirmation message') and
output.toString().contains('warn message') are environment-
dependent. Liquibase 4.27 selects between Slf4jLogService and the
built-in JavaLogService at Scope-init time; the choice depends on
which SLF4J binding is bound *at that moment*. The two service
implementations route INFO output very differently:
Slf4jLogService -> SLF4J -> Logback ConsoleAppender -> stdout
(filtered by root level / per-logger
levels in whichever logback config
Logback found first)
JavaLogService -> java.util.logging -> default ConsoleHandler
-> stderr (no filtering)
In the local dev environment Liquibase falls back to JavaLogService
and the messages end up in captured stderr (Spock captures both),
so the test passes. In the joint validation runner Liquibase picks
Slf4jLogService and the messages get filtered by Logback before
they reach stdout. Since the captured behaviour is being driven by
classpath-and-configuration roulette rather than the code under
test, asserting on it produces flake.
The change being applied is already verified by calledBlocks in
each test method (init / validate / change / rollback closures
record their invocation order). The confirm and warn directives
are exercised by GroovyChange's confirm(String) and warn(String)
methods being invoked from the parsed DSL - if those didn't run,
the changeset wouldn't apply and calledBlocks would be empty.
Drop the brittle output assertions and document why so a future
maintainer doesn't re-add them.
Verified locally on Groovy 5.0.6-SNAPSHOT build #26:
./gradlew :grails-data-hibernate5-dbmigration:test \
--tests 'org.grails.plugins.databasemigration.liquibase.GroovyChangeLogSpec' \
-PmaxTestParallel=3 --rerun-tasks
BUILD SUCCESSFUL (7 tests, 7 successes, 0 failures, 0 skipped)
Surfaced while auditing PR #15557 (Groovy 5 / Spring Boot 4 upgrade)
where build_grails was the only outstanding Groovy joint validation
failure on both 8.0.x and the upgrade branch.
Assisted-by: claude-code:claude-opus-4-7
jamesfredley
force-pushed
the
grails8-groovy5-sb4
branch
from
c985b72 to
0ce8095
Compare
Contributor
|
@jamesfredley You haven't attempted to apply the 11985 PR and see what is fixed? It is still under discussion on the Groovy side. It would be great to know whether it fixes encountered problems. |
Contributor
Author
|
@paulk-asert I will refresh the Groovy 6 canary and do a test with apache/groovy#2529 |
✅ All tests passed ✅🏷️ Commit: bda52ad Learn more about TestLens at testlens.app. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 build #26 (20260506.012755-26) on JDK 21, including the-PgrailsIndy=falsematrix that exposes Groovy 5 trait/interface bytecode bugs. Last audited 2026-05-08.Apache Groovy 5.0.6 was released 2026-05-04 (Maven Central, tag GROOVY_5_0_6). The
5.0.6-SNAPSHOTwe resolve from the Apache snapshots repo currently points at theGROOVY_5_0_Xbranch HEAD, which is 4 commits ahead of the 5.0.6 release tag (post-release dependency bumps + GROOVY-11996groovy.truth.file.exists.enabledsystem property). All 5.0.6 release contents are present in the snapshot. The Groovy team has not yet bumped the snapshot to5.0.7-SNAPSHOT.Target stack
jakarta.servlet,jakarta.validation,jakarta.inject, ...)Remaining workarounds
Cross-referenced against every GROOVY-* ticket fixed in 5.0.6 and every commit on
GROOVY_5_0_XHEAD. Each item below has been re-verified failing on 5.0.6-SNAPSHOT build #26 with the workaround removed.TemplateRendererImpl.render(Map)(ingrails-coreandgrails-shell-cli),TemplateRendererImpl.render(CharSequence/File/Resource, File, Map, boolean)(in both modules), andGenerateControllerCommand.generateFiledefence-in-depthDefaultGroovyMethods.asBoolean(File)on Groovy 5+ returnsfile.exists() && (isDirectory() OR length>0). The previousif (template && destination)guards silently evaluatedfalsefor a not-yet-generated destination File and silently no-opped. Fix iscontainsKey()/ explicit== nullchecks (per @paulk-asert's upstream confirmation). The typed positionaltemplateRenderer.render(Resource, File, Map, boolean)shape inGenerateControllerCommandis kept as defence-in-depth, not as a workaround for a compiler bug.TemplateRendererImpl.groovy(reproducer is misdiagnosed; see Paul's comment)groovy.truth.file.exists.enabled=falsesystem property that reverts to Groovy 4 behaviour, fix-version 5.0.7 (not in 5.0.6 release; onGROOVY_5_0_XHEAD).GrailsASTUtils.java(processVariableScopes),AstUtils.groovy(canonicalisation guard),AbstractMethodDecoratingTransformation.groovy(canonicalisation guard + non-nullVariableScopeonClosureExpression) andResourceTransform.groovynon-nullVariableScopeguard onClosureExpressionVariableScopeVisitorNPEs during canonicalisation on certain Grails AST transformation outputs. Reverting locally breaks:grails-datamapping-tck:compileGroovywithBUG! exception in phase 'canonicalization'.Main.groovy(isolates theClosureWriterNPE half - the canonicalisation NPE remained shape-dependent on Grails-specific transforms)gradle/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 #26.Main.groovy(compiles a Subject twice, indy=true and indy=false, with the same try/catch wrap; only indy=false on Groovy 5 falls through topropertyMissing)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.MySettings.groovy(diagnostic only - shows@Builderis@Retention(SOURCE)upstream, soClass.getAnnotation(Builder)returns null on every Groovy version; the full Spring binding failure path is out of scope)g.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.NamespaceExtension.groovy(TypeCheckingDSL extension stores aPropertyExpressioninunresolvedPropertyand matches by node identity inmethodNotFound; identity is no longer preserved on Groovy 5)Validateable.resolveDefaultNullable()Method.invokereflection bypassTraitReceiverTransformerrewritesthis.defaultNullable()to a static helper call, silently losing the implementing-class override. Workaround uses reflection to keep dynamic dispatch.Validateable.groovyTraitReceiverTransformerchange.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- rewrote therender(Map)body ingrails-core(325e2fee08) andgrails-shell-cli(faef56cfe2); rewrote the typedrender(CharSequence/File/Resource, File, Map, boolean)overloads ingrails-shell-clito use explicit== nullchecks instead of Groovy truthiness (43ad57a296). The previousif (template && destination)guards silently no-opped becauseDefaultGroovyMethods.asBoolean(File)returnsfile.exists() && (isDirectory() OR length>0)for a yet-to-be-generated destination File. Fix per @paulk-asert's upstream confirmation.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 #26 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.TraitPropertyAccessStrategyboolean-getter fallback - either delete the fallback if it has no triggering callers in current GORM tests, or rewrite the surrounding code so the JavaBean-conventions intent is self-evident without a comment.