Community
Participate
Working Groups
If I extract an interface "I" from class "A" in the program below, which contains method "zip()" but not method "zap()", the resulting program will contain a compile-error. The problem is the fact that the methods J.foo(A) and E.foo(A) in the example program are related, despite the fact that one does not override the other. Therefore, the signature of these methods must either be changed as a group, or they must not be changed at all. In this example, we cannot change the signature of E.foo(A), so we can also not change the signature of J.foo(A). I think the solution will be to generate additional type constraints that enforce equality of parameter types and return types for such methods, similar to the way overridden methods are currently handled. -Frank package typeConstraintBug; public class TypeConstraintBug { public static void main(String[] args){ J j = new C(); j.foo(new A()); System.out.println("done"); } } class A { public void zip(){ } public void zap(){ } } interface J { public void foo(A a1); } class B implements J { public void foo(A a3){ a3.zip(); } } class E { public void foo(A a4){ a4.zap(); } } class C extends E implements J { /* no foo() here */ }
This bug is also causing problems for the new generics-related refactorings. We should increase its priority. -Frank
Tobias, is this still an issue.
This marriage of convenience setup is the only ripple method case with the new typeconstraint infrastructure which does not work. Doing this one right would involve building subtype hierarchies with a considerable performance loss. Closing as wont fix