[ https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Milles updated GROOVY-8864: -------------------------------- Labels: traits (was: ) > Backwards compatibility of traits > --------------------------------- > > Key: GROOVY-8864 > URL: https://issues.apache.org/jira/browse/GROOVY-8864 > Project: Groovy > Issue Type: Task > Affects Versions: 2.5.3 > Reporter: Paul King > Assignee: Paul King > Priority: Major > Labels: traits > Fix For: 3.0.0-alpha-4, 2.5.4 > > > In Groovy 2.4 we allow: > {code} > trait Foo<T> { > static T get() { > ... > } > } > class Bar implements Foo<Bar> {} > assert Bar.getMethod("get").returnType.name == 'Bar' > {code} > This produces some useful type information in the generated class: > {code} > class Bar implements Foo<Bar> { > ... > static Bar get() { > ((Foo$Trait$Helper.get(this)) as Bar) > } > ... > } > {code} > It's a little strange in that a spurious generics type appears in the trait > helper class for 2.4 but we ignore it: > {code} > static java.lang.Object<T> get(java.lang.Class<Foo> $static$self) { > ... > } > {code} > 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: > {code} > trait Foo<T> { > static T get() { ... } > } > class Baz<E> implements Foo<E> {} > def bz = new Baz<String>() > assert bz.getClass().getMethod("get").returnType == Object > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)