[ 
https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King resolved GROOVY-8864.
-------------------------------
       Resolution: Fixed
         Assignee: Paul King
    Fix Version/s: 2.5.4
                   3.0.0-alpha-4

I have made our extra checks on generics not apply to traits. This retains the 
desired behavior from Groovy 2.4.  I think we should look to improving the 
underlying approach to achieve this behavior since it is relying on generics 
information existing within the helper class that wouldn't be allowed for Java. 
It isn't a problem with existing JDKs but could leave us exposed if the 
strictness of class checking changed in future versions.

> 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)

Reply via email to