[
https://issues.apache.org/jira/browse/GROOVY-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18091730#comment-18091730
]
Paul King commented on GROOVY-12104:
------------------------------------
@Eric, I accidentally repasted the GROOVY-12105 description into this issue -
fixed now.
> Trait body with T.this.* qualifier produces VerifyError (4.x) /
> ClassCastException (5.x/6.x) — should be a compile error
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12104
> URL: https://issues.apache.org/jira/browse/GROOVY-12104
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
>
> bq. *Editorial*: the description here was incorrectly populated with
> GROOVY-12105's content when filed. Corrected now to describe the intended
> T.this.* bytecode bug.
> Inside a trait body, the qualifier syntax `T.this.<member>` (where T
> is the enclosing trait) compiles successfully but produces invalid or
> mis-typed bytecode that fails at runtime.
> Minimal reproducer:
> {code:groovy}
> trait V {
> static boolean defaultNullable() { false }
> static seen() { V.this.defaultNullable() }
> }
> class Over implements V { static boolean defaultNullable() { true } }
> Over.seen()
> {code}
> Expected: either return a value matching a defined semantic, or
> reject at compile time as a syntax error (T.this has no coherent
> meaning in trait code per GEP-22, where `this` is the implementing
> instance and the trait is not an enclosing scope).
> Actual:
> * Groovy 4.0.32: java.lang.VerifyError "Bad type on operand stack"
> (Type 'java/lang/Class' not assignable to 'groovy/lang/Closure' at
> V$Trait$Helper.seen(Ljava/lang/Class;)Ljava/lang/Object; @1:
> invokevirtual)
> * Groovy 5.0.6 / 6.0.0-alpha-1: java.lang.ClassCastException: Cannot
> cast java.lang.Class to V
> * Bytecode disassembly: {{2ab6 0032 c000 09ba 003f 0000 b0}}
> (aload_0 of $static$self (Class) → invokevirtual expecting Closure)
> The bug shape changed between 4.x and 5.x — the verifier-level
> mismatch on 4.x was apparently fixed but the underlying transform
> still produces wrong code (now ClassCastException at runtime).
> Adjacent cases (helps scope the bug):
> ||Variant||4.0.32||5.0.6 / 6.0.0-alpha-1||
> |Trait static T.this.method()|VerifyError|ClassCastException|
> |Trait static T.this.staticField|VerifyError|VerifyError (still)|
> |Trait *instance* T.this.method()|VerifyError|AbstractMethodError|
> |Plain (non-trait) class T.this.method() in static|Compile error|Compile
> error|
> |Trait static OtherTrait.this.method() (wrong trait)|Compile error|Compile
> error|
> Discovered during the GROOVY-11985 / GROOVY-12093 thread when
> enumerating candidate alternatives Grails could use as workarounds
> for trait-body static dispatch (Eric Milles' comment of 25-Jun-2026
> asked whether `Validateable.this.defaultNullable()` would work).
> *Recommended fix*: reject `T.this.*` in trait code at compile time.
> For "force the trait's own implementation", `T.super.m(...)` is the
> existing supported form. For normal dispatch, `this.m(...)` (which
> follows row-1 override-visible dispatch).
> This aligns with Eric's framing on the companion GROOVY-12105 ticket
> ("Cannot use super in a static context") — Java doesn't have a T.this
> analogue meaningful for traits (T.this is for inner/anonymous-class
> enclosing-instance access; a trait isn't an enclosing scope of its
> implementer), so "reject" is the right answer for the same JLS-
> alignment reason.
> Proposed spec text: GEP-22 v5 § "this, super, and stackable traits"
> item 4 (already drafted in a working branch, would land alongside the
> fix).
> *Related*: GROOVY-11985 (the regression discussion that surfaced
> this), GROOVY-12093 (the @Anchored proposal, where Eric Milles'
> question prompted the empirical sweep), GROOVY-12105 (the companion
> ticket — same workstream, different bug shape).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
