jamesfredley commented on PR #15557: URL: https://github.com/apache/grails-core/pull/15557#issuecomment-4577262665
## Burn-down: GROOVY-12040 backported to `GROOVY_5_0_X` - `@Builder` workaround removed Following @paulk-asert's note that **GROOVY-12040 is now fixed in `GROOVY_5_0_X`**, I verified it against the consumed snapshot and removed the `ConfigurationBuilder` `@Builder`-detection workaround on this branch (`db381c1ac6`). ### Verification that the fix is actually in the snapshot we consume The published `5.0.7-SNAPSHOT` advanced to **`5.0.7-20260529.064309-2`** (2026-05-29 06:43 UTC). I inspected `groovy.transform.builder.Builder` in the old vs new jar directly: | Snapshot build | `@Builder` retention | |---|---| | `...20260522...` (prior cached jar) | `SOURCE` - workaround was genuinely needed | | `5.0.7-20260529.064309-2` (current) | **`RUNTIME`** - workaround removable | `Class.getAnnotation(Builder)` is non-null again, so the `isLikelyBuilderType()` heuristic and its three call-site disjuncts are gone and detection reverts to the pre-Groovy-5 `getAnnotation(Builder)` form. The Spring 7 `Map`-to-typed-config conversion fallbacks in the same file are retained (independent of the Groovy version). **Verified** on `5.0.7-20260529.064309-2` / JDK 21 (forced `--refresh-dependencies --rerun-tasks --no-build-cache`): - `:grails-datastore-core:test --tests "*ConfigurationBuilder*"` -> **9/9 passed** - `:grails-datastore-core:codeStyle` -> green ### Finding: the `AbstractConstraint` half of the old row is a separate, genuinely-required bug Old row 3 bundled `AbstractConstraint` static-init together with the `@Builder` issue, so I tried to drop it too - and a new test immediately caught a real regression. On Groovy 5 `ConstrainedProperty.DEFAULT_MESSAGES.get(code)` returns **null** for every code (the interface-constant map initialiser runs before the `DEFAULT_*_MESSAGE` constants it references are assigned), while `MESSAGE_BUNDLE.getString(code)` resolves the same code correctly. The existing constraint specs never caught this because they all supply a `MessageSource`. So the `MESSAGE_BUNDLE` fallback **stays**, now: - decoupled from GROOVY-12040 and listed as its own remaining workaround #3, - documented inline with the real root cause, and - guarded by a new in-tree reproducer / regression test, `DefaultMessageResolutionSpec` (`:grails-datamapping-validation:test` green). This is the standalone reproducer prior audits said was still owed; it needs its own upstream Groovy ticket. ### Reproducer scan I went through every standalone reproducer repo (`groovy5-builder-simplestrategy-runtime-bug`, `groovy-trait-static-method-override-bug`, `groovy5-variablescope-canonicalization-bug`, `groovy5-controller-action-param-scope-bug`, `groovy5-stc-extension-node-identity-bug`, `groovy5-compiledynamic-trait-bug`). The most recent @paulk-asert comments there are 2026-05-24..2026-05-27 and are all already actioned (GROOVY-12040; GROOVY-12041 g.taglib; the `setVariableScope` and File-truthiness all-version reclassifications). Nothing newer is outstanding. ### Accepted workaround set for Grails 8 on Groovy 5 (4 remain) | # | Workaround | Why it stays | |---|---|---| | 1 | `VariableScopeVisitor` canonicalization guards (3 sites) | NPE in the canonicalization phase still reproduces on `:grails-datamapping-tck:compileGroovy`; not yet filed | | 2 | `boot4-disabled-integration-test-config.gradle` (5 projects) | indy=false controller param-scope loss **and** a SiteMesh3 / Spring 7 incompatibility - cannot drop on the Groovy axis alone | | 3 | `AbstractConstraint` `MESSAGE_BUNDLE` fallback | `DEFAULT_MESSAGES` static-init returns null on Groovy 5 (now reproduced by `DefaultMessageResolutionSpec`); not yet filed | | 4 | `Validateable.resolveDefaultNullable()` reflection | GROOVY-11985 / apache/groovy#2529 still **OPEN** | \#4 is the next removal once #2529 merges and a fixed snapshot publishes - @paulk-asert's earlier validation already confirmed #2529 fixes it end-to-end. Assisted-by: claude-code:claude-4.8-opus -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
