[
https://issues.apache.org/jira/browse/GROOVY-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-12104:
-------------------------------
Description:
_*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).
> 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
>
> _*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)
