groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GROOVY-4908) Improved compiler checking/error messages required when checking interfaces with generics
Date Sun, 26 Aug 2018 03:10:00 GMT

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

Paul King updated GROOVY-4908:
------------------------------
    Affects Version/s: 3.0.0-alpha-3
                       2.5.2

> Improved compiler checking/error messages required when checking interfaces with generics
> -----------------------------------------------------------------------------------------
>
>                 Key: GROOVY-4908
>                 URL: https://issues.apache.org/jira/browse/GROOVY-4908
>             Project: Groovy
>          Issue Type: Improvement
>          Components: Compiler
>    Affects Versions: 2.4.0-beta-3, 3.0.0-alpha-3, 2.5.2
>            Reporter: Paul King
>            Priority: Major
>
> Given this interface:
> {code}
> interface Base {
>   public <T extends CharSequence> T copy1(T arg)
>   public <T extends CharSequence> T copy2(T arg)
>   public <T extends CharSequence> T copy3(T arg)
>   public <T extends CharSequence> T copy4(T arg)
>   public <T extends CharSequence> T copy5(T arg)
>   public <T extends CharSequence> T copy6(T arg)
> }
> {code}
> Then this class doesn't compile with one error (but there should be at least 5 errors):
> {code}
> class Foo implements Base {
>   def copy1(arg) { arg }
>   CharSequence copy2(arg) { arg }
>   def <T> T copy3(T arg) { arg }
>   def <T extends Object> T copy4(T arg) { arg }
>   def <T extends CharSequence> T copy5(T arg) { arg }
>   def <T extends String> T copy6(T arg) { arg }
> }
> {code}
> Current behavior:
> * copy1 through copy4 would be allowed by Java but would count as overloaded non-interface
methods and compile would fail saying Foo wasn't abstract and didn't implement copyN method.
Groovy doesn't complain but I think it should. The existence of those methods is fooling the
later checks that all interface methods are implemented - we need to tighten the checks
> * Java also wouldn't allow copy2 and copy3 above together as they have the same erasure.
Again, we should have a check for that.
> * copy5 passes as it should for both Groovy and Java.
> * copy6 is recognised by Groovy as overloaded method, so we have the correct error message
in that case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message