[codeconsole]

This makes the constructor of a class that implements a trait call the trait helper's $init$ directly, instead of dispatching the call through the meta class. The dispatch cost a dynamic call on every instantiation. In a GraalVM native image it also needed reflection metadata, or construction failed at run time. It came up while making Grails start as a native image without recorded reachability metadata.

The trait initializer call

When a class implements a trait, TraitComposer.applyTrait adds Helper.$init$(this) to the class's object initializer without a method target. The $static$init$ call beside it has one, and so do the trait forwarder methods (GROOVY-11776).

trait Greeting { String greeting = 'hello' }
@CompileStatic class StaticGreeter implements Greeting {}
class DynamicGreeter implements Greeting {}

• StaticGreeter.<init>: ldc Greeting$Trait$Helper; ldc "$init$"; … invokestatic ScriptBytecodeAdapter.invokeMethodN
• DynamicGreeter.<init>: invokedynamic invoke:(Class,LDynamicGreeter;)Object
• Both <clinit>s: invokestatic Greeting$Trait$Helper.$static$init$(Class)

A native image therefore had to register every trait helper's $init$ for reflection, or construction failed with "No signature of static method: $init$". Grails scans for and registers every trait helper for this reason alone.

The change sets the target to the $init$(TraitType) that the helper declares: the AST node for a trait compiled in the same unit, and, for a precompiled trait, the node Traits.findHelpers builds by reflection from the loaded helper class. TraitASTTransformation always generates $init$. A helper that does not declare $init$(TraitType) fails compilation with a GroovyBugError, as Traits.findHelpers already does for a missing helper class.

Constructors now run ALOAD 0; INVOKESTATIC Greeting$Trait$Helper.$init$ (LGreeting;)V in dynamic, @TypeChecked and @CompileStatic classes. That includes the classes withTraits and as Trait generate at run time. The initializers do the same work in the same order. A method added to a helper's meta class no longer replaces $init$, just as it already could not replace $static$init$.

The initializers of final trait fields are called directly too. A final field with an initial value has its own initializer in the helper, $init$<field>(TraitType), or $static$init$<field>(Class) for a static field, which the implementing class calls to set its copy of the field. Dynamic and @TypeChecked classes called it with invokedynamic; @CompileStatic classes already called it directly. Constructors and static initializers now call it with invokestatic in every mode, also for traits compiled by Groovy 4 or 5, and a helper's meta class no longer replaces it.

In a @CompileStatic class, the object initializer, which holds the instance initializer blocks and the $init$ call, is still compiled as before: its calls go through the meta class unless they carry a target, and the $init$ call now does, so the call is direct there too. Compiling the initializer blocks of @CompileStatic classes statically would change their type checking and semantics, and is not part of this change.

Native image

Building without reflection metadata now works for a class that implements a statically compiled trait, or a trait with no fields or initializer blocks. A dynamic trait's $init$ still sets its fields through the implementing class's field-helper accessors with invokedynamic, so those accessors still need metadata.

Tests

TraitInitBytecodeTest checks constructor bytecode in dynamic, type-checked and static classes for:

• traits with and without fields;
• several traits, including a super trait, with the calls in order;
• a generic trait;
• a @SelfType trait;
• a precompiled trait;
• final instance and static fields;
• an implements clause in the other order, and subclasses;
• anonymous classes, created in a method and in a closure;
• a @CompileStatic trait;
• a precompiled helper without $init$, which must fail compilation.

It also checks field initialization, initialization order, runtime trait application, and that a meta-class override of $init$ is no longer called. Without the change, 37 of its 47 tests fail: all the bytecode tests, the missing-$init$ test and the meta-class test. The 10 field and order tests pass either way.

The groovy, gls, bugs and org.codehaus.groovy packages pass (15,542 tests). The Checkstyle and CodeNarc gates pass.

Backport

Grails 9 builds with Groovy 6.0.x, and the javap above is from 6.0.0. The change applies cleanly to GROOVY_6_0_X. A backport would let Grails 9 stop registering $Trait$Helper classes for $init$. The field helpers of traits that are not statically compiled still need metadata.

JIRA: GROOVY-12491

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.6861%. Comparing base (5b077f9) to head (733d5c8).
⚠️ Report is 7 commits behind head on master.

Additional details and impacted files

@@                Coverage Diff                 @@
##               master      #3025        +/-   ##
==================================================
+ Coverage     73.6711%   73.6861%   +0.0150%     
- Complexity      42584      42598        +14     
==================================================
  Files            1678       1678                
  Lines          146907     146926        +19     
  Branches        27790      27794         +4     
==================================================
+ Hits           108228     108264        +36     
+ Misses          28528      28515        -13     
+ Partials        10151      10147         -4     

Files with missing lines	Coverage Δ
...codehaus/groovy/transform/trait/TraitComposer.java	83.0247% <100.0000%> (+0.7096%)	⬆️
...va/org/codehaus/groovy/transform/trait/Traits.java	86.5772% <ø> (ø)

... and 18 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[daniellansun]

Thanks for the focused GROOVY-12491 fix. Pinning the trait-helper $init$ call with MethodCallExpression.setMethodTarget in TraitComposer.applyTrait is the same pattern already used for trait forwarders (createForwarderMethod) and for $static$init$, and it correctly yields a direct INVOKESTATIC …$Trait$Helper.$init$ for dynamic, @TypeChecked, and @CompileStatic implementers alike. Deferring any broader “compile object initializers statically” change (as the later commit on this PR does) keeps the blast radius small. TraitInitBytecodeTest is unusually careful about bytecode shape, init order, precompiled traits, and the intentional MetaClass bypass.

I am leaving a COMMENT (not an approval): the happy path looks right, but a few contract / robustness edges should be tightened before this lands.

Observations / concerns

1. getDeclaredMethod can return null with no guard.
   initCall.setMethodTarget(helperClassNode.getDeclaredMethod(Traits.INIT_METHOD, new Parameter[]{new Parameter(trait, Traits.THIS_OBJECT)})) assumes the helper always declares $init$(TraitType) under exact ClassNode parameter equality. If the lookup misses (precompiled helper with a differently-represented parameter type, a future helper shape, generics erasure mismatch), setMethodTarget(null) silently falls back to the old MetaClass path — the opposite of what the bytecode assertions require, and easy to miss without a failure. Please either:

   • assert / throw a GroovyBugError when the method is missing (preferred; this is a compiler invariant), or
   • resolve via helperClassNode.getMethods(Traits.INIT_METHOD) filtered by arity/$self and document why soft fallback is acceptable.
     A regression that deliberately breaks the lookup (or a comment + test on precompiled generic traits with bridge/$self types) would lock this.

2. setImplicitThis(false) is not set on the init call.
   Forwarders set both setMethodTarget and setImplicitThis(false). The receiver here is a ClassExpression, so today’s InvocationWriter.writeDirectMethodCall still emits a static call, but the AST is inconsistent with the sibling $static$init$ / forwarder pattern. Setting initCall.setImplicitThis(false) (and optionally setSafe(false)) would make the intent explicit and protect against future MCE default changes.

3. Intentional MetaClass / EMC behavioural break needs a sharper user-facing note.
   testTraitInitializerIsNotDispatchedThroughMetaClass correctly shows that an EMC static $init$ on the helper is ignored for compile-time implementers and for withTraits / as. That is a real, observable change for anyone who intercepted trait field init via the helper’s MetaClass. The test comment is good; please also put a one-line note on Traits.INIT_METHOD or in the trait release notes / JIRA so this is not only discoverable by reading the test. If runtime trait proxies have a separate init path that already bypassed MetaClass, say so explicitly so readers do not over-generalize.

4. $static$init$ already targeted; instance $init$ is the gap — confirm field-level helpers.
   Static init already used setMethodTarget (albeit on a stub MethodNode). Instance $init$ is what this PR fixes. The per-field baseName + fieldNode.getName() static calls around the field-helper path still go through callX without a target. Out of scope is fine, but worth a sentence in the PR discussion or a follow-up JIRA if those can still miss on native-image / shrinker setups for the same reason $init$ could.

5. Init ordering is locked for one shape only.
   testInitializersOfSeveralTraitsAreCalledDirectlyInOrder / testInitializationOrderIsUnchanged pin implements B, C → C, B, A and the relative order vs instance fields / object initializer / ctor. Good. Please also cover:

   • implements C, B (declaration-order sensitivity), and
   • a class that both extends a trait-implementing superclass and adds another trait (super’s $init$ vs this class’s),
     so a future TraitComposer reorder cannot silently change construction semantics under the new direct calls.

6. Anonymous implementers / SAM-style new Trait() {}.
   testTraitFieldsAreInitialized covers Greeter.anonymous(). Bytecode assertion for the anonymous class’s <init> (direct $init$) would match the thoroughness of the named-class cases and catch any AIC-specific composer path that still omits the target.

Test gaps I would still like to see

• Failure mode when $init$ cannot be resolved on the helper (item 1), or at least an assert that getMethodTarget() != null after compose in a unit-level composer test.
• Trait declaration order swap + trait on superclass + additional trait on subclass (item 5).
• Optional: bytecode assert on new Greeting() {} (item 6).
• Optional: @CompileStatic trait (not only implementer) with field initializers consumed by a dynamic implementer.

Non-blocking nits

• The production diff is a four-line change; the new test class is the bulk — appreciated. A @since / JIRA pointer next to Traits.INIT_METHOD would help future bisects.
• assertDirectInitCalls matches on INVOKESTATIC …$Trait$Helper.$init$ (L…;)V and rejects "$init$" string constants — solid. Consider also rejecting INVOKEDYNAMIC with $init$ as bootstrap/name arg if indy ever grows a path here.
• Temp-dir cleanup in testInitializerOfPrecompiledTraitIsCalledDirectly is good; traitUnit.compile() without an explicit phase is fine given defaults.

Stance

Directionally I am in favour: small, idiomatic, aligned with existing trait forwarder targeting, and well tested on the bytecode surface. The main review asks are hardening the getDeclaredMethod miss path, aligning MCE flags with forwarders, and making the MetaClass bypass an explicit documented contract rather than only a test comment. I am not approving yet; happy to re-review once those are addressed.

[codeconsole]

Pushed 073ef08. Replies in the order of the review:

1. Fixed in 1c7809b: a miss throws a GroovyBugError naming the helper and the trait, as Traits.findHelpers already does for a missing helper class. testPrecompiledTraitHelperWithoutInitializerIsRejected strips $init$ from a precompiled helper with ASM and expects the error; it fails without the guard. getDeclaredMethod compares parameter types by class name, so generic, @SelfType and precompiled traits match (testInitializerOfGenericTraitIsCalledDirectly, testInitializerOfSelfTypeTraitIsCalledDirectly, testInitializerOfPrecompiledTraitIsCalledDirectly).
2. Done in 9f2c735 for both $init$ and $static$init$; the $static$init$ call did not set it either, only the forwarders did. The field initializer calls from 177b7cc set it too. The bytecode is unchanged (38 class files compared). safe is already false by default.
3. Done in 716bbd9: the note is on Traits.INIT_METHOD, and the JIRA description says the same. Runtime trait application has no separate path: ProxyGeneratorAdapter compiles a $TraitAdapter class that TraitComposer composes like any other class, so on 6.0.0 withTraits and as also went through the meta class, and now they do not. testTraitInitializerIsNotDispatchedThroughMetaClass covers the compiled classes, a @TypeChecked class and both runtime forms.
4. Done in this PR, 177b7cc: the field initializers ($init$<field>, $static$init$<field>) are now calls with the helper method as target. Dynamic and @TypeChecked classes called them with invokedynamic (@CompileStatic ones were already direct); every mode now emits invokestatic, also against traits compiled by Groovy 4.0.24 and 5.0.3, and with indy off. testFieldInitializersOfTraitAreCalledDirectly and the extended precompiled test fail without it.
5. Added in 073ef08: testInitializersFollowTheOrderOfTheImplementsClause (implements C, B gives B, A, C), testSubclassCallsTheInitializersOfTheTraitsItDeclares and testInitializationOrderWithSwappedTraitsAndSuperclass. The orders match 6.0.0, including a subclass that declares its superclass's trait again through a sub-trait and so initializes its own copy of that trait's fields, as _traits.adoc describes.
6. Added in 073ef08: testInitializerIsCalledDirectlyFromAnonymousClass checks the constructors of anonymous classes created in a method and in a closure.

Test gaps:

• $init$ that cannot be resolved: testPrecompiledTraitHelperWithoutInitializerIsRejected (1c7809b).
• Declaration order and superclass/subclass traits: item 5.
• new Greeting() {}: item 6.
• @CompileStatic trait with field initializers: testStaticallyCompiledTraitIsInitializedDirectly (073ef08), with dynamic, @TypeChecked and @CompileStatic implementers; it also checks that the trait's own $init$ makes no dynamic call.

Nits:

• The note on Traits.INIT_METHOD names GROOVY-12491. The sibling constants in Traits carry no @since, so none was added.
• Done in 073ef08: the assertions also reject an invokedynamic call site whose bootstrap arguments name an initializer, and cover the field initializers.
• Kept; the new precompiled test uses the same pattern.

TraitInitBytecodeTest now has 47 tests; with the pre-PR TraitComposer, 37 fail. 14,443 tests pass on JDK 21, and bugs.Groovy12142, bugs.Groovy12363 and TraitInitBytecodeTest on JDK 17.

[daniellansun]

Thanks for the follow-up on tip 073ef08. I re-checked TraitComposer’s init targeting and your reply to my earlier COMMENT on 865a434.

Prior asks on the $init$ path — closed

1. Missing helper method. getDeclaredMethod miss now throws GroovyBugError naming helper and trait; testPrecompiledTraitHelperWithoutInitializerIsRejected (ASM-stripped helper) fails without the guard. Parameter matching by class name covers generic / @selftype / precompiled cases.

2. MCE flags. setImplicitThis(false) on $init$, $static$init$, and the field initializer calls aligns with forwarders; bytecode unchanged across the compared class files.

3. MetaClass bypass. Note on Traits.INIT_METHOD (and JIRA) states that compile-time implementers and runtime withTraits / as (via ProxyGeneratorAdapter → TraitComposer) no longer dispatch $init$ through the helper’s MetaClass. Test covers compiled, @TypeChecked, and both runtime forms.

4. Field-level helpers. $init$<field> / $static$init$<field> are now direct invokestatic in every mode, including against Groovy 4/5 precompiled traits — closes the native-image hole I left as a follow-up.

5–6. Implements-clause order, subclass + superclass traits, and anonymous-class <init> bytecode assertions are in place. @CompileStatic trait with dynamic / TC / SC implementers covered.

Why I am not approving yet

1. Merge conflicts. Tip is dirty against current master. Please rebase / resolve first.

2. Scope beyond GROOVY-12491. The tip also includes ClassInfo.remove preserving DGM/extension methods, JDK 17 method-handle asType-cache hygiene, outer-method resolution from inner classes, joint-compilation trait initializer double-run, Object methods in SC closures, Class methods from static context, and related closure-delegation fixes. Several of those are important (especially ClassInfo.remove for the integration-guide sweep), but they are distinct risk domains from “call $init$ with INVOKESPECIAL/INVOKESTATIC.” Prefer:

   • a focused PR (or clearly separable commit series) for trait $init$ / field-init direct calls + TraitInitBytecodeTest, aimed at the Grails native-image backport; and
   • ClassInfo / MH-cache / closure-Object-method / joint-init as their own JIRA(s), so a ClassInfo regression cannot block the trait-init win (or vice versa).

If you prefer to keep one PR, please at least label the commits in the description by JIRA so reviewers and release notes can reason about cherry-picks to GROOVY_6_0_X.

Residual on the trait-init slice (non-blocking once conflicts clear)

• Dynamic traits still need field-helper metadata in native images — already stated; fine.
• Rejecting INVOKEDYNAMIC bootstrap args that name $init$ in the bytecode asserts is a nice hardening.

Stance

COMMENT, not approval, while the tip conflicts and while ClassInfo/MH/closure work rides along unmarked. The trait-init design itself looks ready: idiomatic setMethodTarget, hardened miss path, and excellent bytecode coverage. Happy to approve a conflict-free, clearly scoped $init$ slice (or this PR after rebase + labelling) on a short re-review. Thank you for addressing every earlier point carefully.

[codeconsole]

@daniellansun Thanks. This PR is now only the trait initializer change: the six $init$ / field-initializer commits on current master, no conflicts. The other fixes have their own issues and pull requests, each from master:

• GROOVY-12574 (GROOVY-12574: Call an outer class method on the right enclosing instance #3106): an outer class method called from an inner class runs on the right enclosing instance
• GROOVY-12575 (GROOVY-12575: Run a trait's instance initializer blocks once under joint compilation #3108): a trait's instance initializer blocks run once under joint compilation
• GROOVY-12576 (GROOVY-12576: SC: resolve Object methods in closures through the delegate and owner #3102): SC: toString(), hashCode(), equals() and getClass() in closures go to the delegate and owner (regression in 5.0)
• GROOVY-12577 (GROOVY-12577: SC: call methods of Class on the class object in a static context #3103): SC: methods of Class called without a receiver in a static context (regression in 5.0)
• GROOVY-12578 (GROOVY-12578: Return the result of a closure's own method when the delegate and owner lack it #3104): a closure's own method runs once when the delegate and owner lack it (regression in 6.0)
• GROOVY-12579 (GROOVY-12579: Keep no discarded class loader reachable through method handle caches on JDK 17 #3095): no discarded class loader kept by method handle caches on JDK 17
• GROOVY-12580 (GROOVY-12580: Keep the default Groovy methods of a class whose ClassInfo was removed #3096): ClassInfo.remove keeps the default Groovy methods; builds on GROOVY-12579: Keep no discarded class loader reachable through method handle caches on JDK 17 #3095, whose fix the documented-sweep test needs on JDK 17
• GROOVY-12581 (GROOVY-12581: SC: make dynamic calls on a closure delegate as normal method calls #3107): SC: delegating closures in instance initializer blocks with a Java delegate (regression in 5.0)

None of them is needed by the trait change. The trait change applies cleanly to GROOVY_6_0_X.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: 733d5c8
▶️ Tests: 125110 executed
⚪️ Checks: 26/26 completed

---

Learn more about TestLens at testlens.app/docs.