[
https://issues.apache.org/jira/browse/GROOVY-12491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134635#comment-18134635
]
ASF GitHub Bot commented on GROOVY-12491:
-----------------------------------------
codeconsole commented on PR #3025:
URL: https://github.com/apache/groovy/pull/3025#issuecomment-6513959319
@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 (#3106): an outer class method called from an inner class
runs on the right enclosing instance
- GROOVY-12575 (#3108): a trait's instance initializer blocks run once under
joint compilation
- GROOVY-12576 (#3102): SC: `toString()`, `hashCode()`, `equals()` and
`getClass()` in closures go to the delegate and owner (regression in 5.0)
- GROOVY-12577 (#3103): SC: methods of `Class` called without a receiver in
a static context (regression in 5.0)
- GROOVY-12578 (#3104): a closure's own method runs once when the delegate
and owner lack it (regression in 6.0)
- GROOVY-12579 (#3095): no discarded class loader kept by method handle
caches on JDK 17
- GROOVY-12580 (#3096): `ClassInfo.remove` keeps the default Groovy methods;
builds on #3095, whose fix the documented-sweep test needs on JDK 17
- GROOVY-12581 (#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`.
> Classes implementing a trait call the helper's $init$ through the meta class
> ----------------------------------------------------------------------------
>
> Key: GROOVY-12491
> URL: https://issues.apache.org/jira/browse/GROOVY-12491
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static compilation
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> 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). Every constructor
> therefore dispatches the call through the meta class of the helper, even in
> {{@CompileStatic}} classes:
> {code:groovy}
> trait Greeting { String greeting = 'hello' }
> @CompileStatic class StaticGreeter implements Greeting {}
> class DynamicGreeter implements Greeting {}
> {code}
> * {{StaticGreeter.<init>}}: {{ldc Greeting$Trait$Helper; ldc "$init$"; ...
> invokestatic ScriptBytecodeAdapter.invokeMethodN}}
> * {{DynamicGreeter.<init>}}: {{invokedynamic
> invoke:(Class,LDynamicGreeter;)Object}}
> * the static initializer of both: {{invokestatic
> Greeting$Trait$Helper.$static$init$(Class)}}
> This costs a dynamic dispatch on every instantiation. A GraalVM native image
> has to register every trait helper's {{$init$}} for reflection, or
> construction fails with "No signature of static method: $init$".
> Proposed fix: give the {{$init$}} call its method target, the
> {{$init$(TraitType)}} method the helper declares, so constructors call it
> with {{invokestatic}} in dynamic, {{@TypeChecked}} and {{@CompileStatic}}
> classes. The initializers of final trait fields ({{$init$<field>}},
> {{$static$init$<field>}}) get their method targets too, and a helper that
> does not declare {{$init$(TraitType)}} fails compilation with a
> {{GroovyBugError}}.
> With this change a method added to the helper's meta class (for example with
> ExpandoMetaClass) no longer replaces {{$init$}} or a field initializer, as it
> already could not replace {{$static$init$}}. This includes the classes that
> {{withTraits}} and {{as Trait}} generate at run time, which are composed the
> same way.
> PR: https://github.com/apache/groovy/pull/3025
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
