[
https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8864:
------------------------------
Affects Version/s: 2.5.3
> 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
> 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
(v7.6.3#76005)
