You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Eric Milles (Jira)" <ji...@apache.org> on 2022/11/11 20:11:00 UTC

[jira] [Commented] (GROOVY-7204) Static type checking and compilation fail when multiple generics in use

    [ https://issues.apache.org/jira/browse/GROOVY-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17632541#comment-17632541 ] 

Eric Milles commented on GROOVY-7204:
-------------------------------------

{code:groovy}
class Repository<T, S extends Serializable> {
  void delete(T arg) { assert true }
  void delete(S arg) { assert false : 'wrong method invoked' }
}
@groovy.transform.CompileStatic
def test() {
  def r = new Repository<String,Long>()
  r.delete('foo')
}
test()
{code}
This is a very interesting case.  I tried it in Java and it works as described (static selection of {{delete(T)}} aka {{delete(String)}}.  However the dynamic runtime selects {{delete(S)}} because the erasure {{Serializable}} is a closer match for {{String}}.  I wonder if it would be better to have consistent behavior for SC and STC or instead to have SC align with Java's behavior.

> Static type checking and compilation fail when multiple generics in use
> -----------------------------------------------------------------------
>
>                 Key: GROOVY-7204
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7204
>             Project: Groovy
>          Issue Type: Bug
>          Components: Static compilation, Static Type Checker
>    Affects Versions: 2.3.8
>            Reporter: Mauro Molinari
>            Assignee: Daniel Sun
>            Priority: Critical
>             Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.0-rc-3
>
>
> Consider the following interfaces:
> {code:title=CrudRepository.java}
> package f;
> import java.io.Serializable;
> public interface CrudRepository<T, S extends Serializable> {
> 	void delete(S arg);
> 	void delete(T arg);
> }
> {code}
> {code:title=MyRepository.java}
> package f;
> public interface MyRepository extends CrudRepository<String, Long> {
> }
> {code}
> The following implementation class:
> {code:title=MyRepositoryImpl.java}
> package f;
> public class MyRepositoryImpl implements MyRepository {
> 	@Override
> 	public void delete(String arg) {
> 		System.out.println("String");
> 	}
> 	@Override
> 	public void delete(Long arg) {
> 		System.out.println("Long");
> 	}
> }
> {code}
> And the following Groovy class:
> {code:title=MyClass.groovy}
> package f
> import groovy.transform.CompileStatic;
> import groovy.transform.TypeChecked;
> @TypeChecked
> class MyClass {
> 	static MyRepository factory() {
> 		return new MyRepositoryImpl()
> 	}
> 	
> 	static void main(String[] args) {
> 		MyRepository r = factory()
> 		r.delete('foo')
> 	}	
> }
> {code}
> Static type checking returns the following error:
> {noformat}
> MyClass.groovy: 15: [Static type checking] - Cannot call f.MyRepository#delete(S) with arguments [java.lang.String]
> {noformat}
> The same applies if you use {{@CompileStatic}} instead of {{@TypeChecked}}.
> Note that if, In the previous code, you change the method {{main}} by replacing:
> {code}
> MyRepository r = factory()
> {code}
> with: 
> {code}
> MyRepository r = new MyRepositoryImpl()
> {code}
> compilation succeeds. However in real code this might not be possible (the {{MyRepository}} instance may be injected and auto-generated, think of Spring Data for instance).
> The only workaround is (yet again...) to disable static type checking and static compilation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)