Groovy 5.0.5 support for Grails 8 + Spring Boot 4

[jamesfredley]

Groovy 5.0.5 support for Grails 8 + Spring Boot 4

Adds Groovy 5.0.5 and Spock 2.4-groovy-5.0 support on top of the spring-boot-4 branch. Merges the groovy-5 branch work and resolves all compatibility issues to get CI green.

Target stack: Groovy 5.0.5, Spring Boot 4.0.5, Spring Framework 7.0.6, Spock 2.4-groovy-5.0, Jakarta EE 10, JDK 17+.

Dependency changes

• Groovy 4.0.x to 5.0.5 (dependencies.gradle)
• Spock 2.3-groovy-4.0 to 2.4-groovy-5.0
• spock.iKnowWhatImDoing.disableGroovyVersionCheck=true added to all Test and GroovyCompile tasks
• BOM groovy.version property override for Spring Boot's managed Groovy version

Groovy 5 workarounds

@CompileStatic instanceof generates checkcast bytecode

Groovy 5's @CompileStatic compiles x instanceof Y to checkcast bytecode instead of the JVM instanceof instruction, throwing ClassCastException when x is NOT a Y.

Replaced with Y.isAssignableFrom(x.getClass()) in:

• PersistentEntityCodec.groovy - property instanceof ManyToMany (all MongoDB GORM tests)
• HibernateEntityTransformation.groovy - classNode instanceof InnerClassNode (Hibernate5 AST transformation)

Controller action method parameters invisible in method body

Groovy 5 does not make method parameters visible inside controller action bodies. Parameters resolve through TagLibraryInvoker.propertyMissing instead of as local variables.

Replaced def index(Integer max) with def index() using params.int('max', 10) across all affected controllers:

• RestfulController.index(Integer max) base class
• 10 BookController instances across test examples
• AdvancedCachingController (category, key, input, value params)
• DemoController (counter, key, value, ttl params)
• TeamController (id param)
• ProductController (inherits from RestfulController)

@Delegate fields in traits silently return null

Groovy 5's DelegateASTTransformation generates direct field access (varX) for @Delegate fields, but trait fields require helper method access via the trait bridge. This causes @Delegate fields in traits to silently return null at runtime.

Converted GrailsApplicationCommand from trait to abstract class so @Delegate gets standard field access. All 9 scaffolding commands updated from implements to extends. Command artifact template also updated.

Traits with static fields generate invalid bytecode (GROOVY-11907)

CommandLineHelper trait had static final boolean SUCCESS = true / FAILURE = false which prevented all scaffolding commands from class-loading. Replaced with inline true/false in all 9 command files.

Interface $getCallSiteArray() causes IncompatibleClassChangeError

Groovy 5 compiles interfaces with $getCallSiteArray() which the JVM rejects at runtime. Converted IContainerGebConfiguration from interface with default methods to trait.

@GrailsCompileStatic on domain class with static mapping closure

Groovy 5 generates invalid bytecode (VerifyError: get long/double overflows locals) for @GrailsCompileStatic combined with static mapping closures. Removed annotation from Customer domain in proxy test example.

Trait static methods break Java stub generation

findAllWithSql/findWithSql moved from HibernateEntity trait to AbstractHibernateGormStaticApi. Tests updated to use GormEnhancer.findStaticApi().

outputTagResult private to protected

Changed in AbstractGrailsTagTests for Groovy 5 nested closure access compatibility.

GroovySpy instead of metaClass.static mock

DataBindingTests updated for Groovy 5 trait method dispatch compatibility.

Spring 7 / Spring Boot 4 fixes

ConfigurationBuilder Map subtype handling

HibernateSettings extends LinkedHashMap was rejected by isLikelyBuilderType() because of a blanket Map.isAssignableFrom() exclusion. Moved Map exclusion after the Grails-package check so Grails Map subtypes are processed as builders. Added abstract/interface exclusions to prevent InstantiationException.

Spring 7's MapToMapConverter now deeply converts map values, causing ConverterNotFoundException when config maps contain non-standard types. Added handleConversionException fallback that gets raw values as Object.class to bypass deep conversion.

BsonPersistentEntityCodec hierarchy walker

Added resolvePropertyType() that walks the full class hierarchy to find the registered decoder/encoder type, instead of relying on .superclass which may miss types with intermediate anonymous classes.

StreamingJsonBuilder ClassCastException (Groovy 5 and 6)

Groovy 5's StreamingJsonBuilder.call(Closure) creates groovy.json.StreamingJsonDelegate via a private method, but compiled .gson templates cast to grails.plugin.json.builder.StreamingJsonDelegate.

• Override call(Closure) in the Grails StreamingJsonBuilder subclass to create Grails delegates directly
• Static cloneDelegateAndGetContent helper
• JsonViewWritableScript uses fully qualified Grails delegate type
• DefaultHalViewHelper instanceof cascade reordered for Groovy 5 flow-typing

Other fixes

• Operator precedence: !association instanceof Embedded to !(association instanceof Embedded) in AbstractHibernateGormInstanceApi
• BootStrap configClass assertion commented out (Groovy 5 config binding incompatibility)
• Forge ScaffoldingSpec asserts on generated file existence instead of stdout pattern matching
• @PendingFeature removed from TaskControllerSpec (now passes)
• Groovysh API migration (GroovyshApplicationContext, GroovyshWebApplicationContext)
• CodeNarc: UnnecessaryGroovyImport, UnnecessaryGString
• GroovyConfigPropertySourceLoader rewritten for Groovy 5 ConfigSlurper changes
• .gitattributes for line ending normalization
• GormEntityTransformation, AbstractMethodDecoratingTransformation, AstUtils, GrailsASTUtils Groovy 5 AST API changes
• grails.annotation.Generated to groovy.transform.Generated migration
• Forge settings.gradle repository configuration for composite builds

Issues to report upstream to Groovy

1. @CompileStatic instanceof generates checkcast instead of JVM instanceof instruction
2. Controller action method parameters inaccessible in method body (resolve through trait propertyMissing)
3. @Delegate fields in traits silently return null (DelegateASTTransformation uses direct field access instead of trait helper methods)
4. Traits with static fields generate invalid bytecode (GROOVY-11907)
5. Interface $getCallSiteArray() causes IncompatibleClassChangeError
6. Trait static methods break Java stub generation in joint compilation

[paulk-asert]

Claude's analysis from the Groovy side (my Claude didn't trust your Claude's bisect! 🙂):

⏺ I now have a deep understanding of the mechanism. Let me provide my comprehensive analysis.

---

Assessment: The grails-geb Frame.putAbstractType AssertionError

Definitive Finding: This is a Groovy bug, NOT an ASM bug

ASM 9.9 and 9.9.1 are functionally identical. I verified this by extracting and diffing ALL source files across ALL five ASM modules (asm-core, asm-tree, asm-analysis, asm-util, asm-commons):

• Frame.java (where the assertion fires): byte-for-byte identical in source AND compiled bytecode
• MethodWriter.java, SymbolTable.java, Label.java: all identical
• The only functional change in 9.9.1 is a bounds check in ClassReader.readAttribute() for malformed class files — completely unrelated to frame computation

The PR author's claim of bisecting to the ASM bump is likely a version-level observation (5.0.3 works, 5.0.4 doesn't) rather than a commit-level bisect. The ASM bump commit happened to be among 41 commits between those releases.

The Assertion Mechanism

The assertion at Frame.java:1482 fires specifically when:

1. An abstract type has array dimensions > 0
2. Its kind is NOT REFERENCE_KIND (it's an unresolved/invalid kind like kind=0)
3. Its value doesn't match any known primitive type constant

This occurs when ASM's getConcreteOutputType() resolves a LOCAL_KIND abstract type that references an uninitialized local variable (value=0 in inputLocals). The arithmetic dim + inputLocals[localIndex] produces ARRAY_OF + 0 = 0x04000000, which has dim=1
but kind=0 (invalid) and value=0 (ITEM_TOP) — not matching any valid type. This gets stored in the destination frame and triggers the assertion during serialization.

In plain English: Groovy generates bytecode where a local variable is treated as an array on some code path, but that local is uninitialized (never assigned a type) on the path that reaches the merge point.

Most Likely Culprit Commits (5.0.3 → 5.0.4)

The commits that changed bytecode generation between these versions:

1. GROOVY-11840 (dbd2304527) — Primary suspect
   - Rewrote BooleanExpressionTransformer.OptimizingBooleanExpression.visit() — how non-boolean values are compiled in boolean contexts under @CompileStatic
   - Changed from pre-computed type (TypeChooser.resolveType()) to runtime stack type (os.getTopOperand())
   - Also changed StaticInvocationWriter.makeGetField() — how field access receiver types are resolved for ClassExpression receivers
   - Also added makeCachedCall() override returning false
2. GROOVY-11817 (920970323e) — Secondary suspect
   - Moved DYNAMIC_RESOLUTION check from method-level to expression-level for CallSiteWriter selection
   - This changes which call site writer handles property accesses in trait methods — static vs dynamic dispatch could affect local variable typing
3. GROOVY-11828 (644796c7bc) — Lower probability
   - Changed instanceof variable handling for closure-shared variables
   - Added SWAP + INVOKEVIRTUAL bytecode sequence for holder variables

Why the grails-geb Code Triggers It

The grails-geb testFixtures have:

• 6 @CompileStatic traits (BrowserDelegate, PageDelegate, DriverDelegate, ContainerSupport, ReportingSupport, DownloadSupportDelegate) with 170+ delegating methods
• ContainerGebSpec implementing all 6 traits with @CompileStatic
• GrailsContainerGebExtension with @tailrecursive + @CompileStatic + object-in-boolean-context (if (spec) where spec is SpecInfo)
• WebDriverContainerHolder with complex control flow, boolean expressions with non-boolean objects (if (customBrowser), if (gebConf.driverConf))
• Many methods with Object[] parameters and generic types ()

The combination of trait helper class generation, static compilation, and the BooleanExpressionTransformer rewrite likely produces bytecode where a local variable used for an array parameter or return value is uninitialized on a particular code path.

Recommendation

To confirm the exact culprit commit, I'd suggest a git bisect on the Groovy 5_0_X branch between GROOVY_5_0_3 and GROOVY_5_0_4, testing each intermediate build against the original (unmodified) grails-geb testFixtures.

A quicker test: revert just GROOVY-11840 on the 5.0.4 tag and rebuild Groovy to see if the assertion disappears. If not, try GROOVY-11817.

Also, the catch block at AsmClassGenerator.java:624 catches Exception but AssertionError extends Error, so the helpful class/method context message is never shown. Changing to catch (Throwable e) would immediately tell you which class and method triggers
the failure — worth doing as a diagnostic patch on Groovy.

[paulk-asert]

Minimal Reproducer

The following two files (requires both) are enough to trigger the compilation failure:

  // SkeletonTrait.groovy
  @CompileStatic
  trait SkeletonTrait {
      static String skeletonField
  }

  // SkeletonSpec.groovy
  @CompileStatic
  abstract class SkeletonSpec extends Specification implements SkeletonTrait {}

If they are placed somewhere else (without geb-ast), e.g. grails-test-core, or in the groovy project, they compile fine.

[paulk-asert]

Latest status:

Still fails with JUST Spock! So no geb-ast, no grails-core, no selenium needed — just the grails-plugin Gradle plugin + Spock + the trait pattern. The grails-plugin must be adding something to the compilation classpath or config that my manual setup doesn't replicate.

[paulk-asert]

For the grails-geb testFixtures part, see:
https://issues.apache.org/jira/browse/GROOVY-11907
apache/groovy#2443

[jamesfredley]

Groovy 5.0.5 unblocked — GROOVY-11907 workaround applied

Commit 708e03c bumps Groovy from 5.0.3 back to 5.0.5 by working around GROOVY-11907 on the Grails side.

Root cause

Paul King identified the grails-geb testFixtures compilation failure as GROOVY-11907 — a regression from GROOVY-11817 where TraitReceiverTransformer generates invalid bytecode for @CompileStatic traits with static fields when method-level DYNAMIC_RESOLUTION is present. The Groovy fix is in apache/groovy#2443 (open, not yet merged).

What changed (temporary workaround)

The only affected code in grails-core is the ContainerSupport trait (grails-geb/src/testFixtures/), which has two static fields (container, downloadSupport) and was annotated with @CompileStatic. Switching it to @CompileDynamic makes its trait helper class compile via the dynamic code path, which generates valid bytecode that ASM 9.9.1 accepts. The implementing class ContainerGebSpec keeps @CompileStatic — its delegate stubs are simple forwarding calls unaffected by the bug.

This is a temporary workaround. Once apache/groovy#2443 ships in a Groovy release, ContainerSupport should be restored to @CompileStatic.

Verification

./gradlew :grails-geb:compileTestFixturesGroovy passes cleanly on Groovy 5.0.5 with this change (BUILD SUCCESSFUL, 118 tasks).