[GROOVY-8864] Backwards compatibility of traits

• Type: Task
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.5.3
• Fix Version/s: 3.0.0-alpha-4, 2.5.4
• Labels: traits
• Assignee: Paul King
• Reporter: Paul King
• Created: 31/Oct/18 08:12
• Updated: 22/Sep/22 16:33
• Resolved: 02/Nov/18 06:52

Description

In Groovy 2.4 we allow:

trait Foo<T> {
  static T get() { 
    ...
  }
}

class Bar implements Foo<Bar> {}
assert Bar.getMethod("get").returnType.name == 'Bar'

This produces some useful type information in the generated class:

class Bar implements Foo<Bar> { 
    ...
    static Bar get() {
        ((Foo$Trait$Helper.get(this)) as Bar)
    }
    ...
}

It's a little strange in that a spurious generics type appears in the trait helper class for 2.4 but we ignore it:

static java.lang.Object<T> get(java.lang.Class<Foo> $static$self) {
    ...
}

In 2.5, we tightened this up to behave more like Java where you can't use a class's generic type parameters in static methods or static fields. However, a trait isn't a class but rather a mechanism for creating classes.

This issue is to look at whether we can provide the 2.4 benefit of having type information in the generated class but avoid any spurious generics info appearing where it shouldn't.

As some additional information, the following example shows that even in 2.4, not all cases worked:

trait Foo<T> {
  static T get() { ... }
}

class Baz<E> implements Foo<E> {}

def bz = new Baz<String>()
assert bz.getClass().getMethod("get").returnType == Object