Community
Participate
Working Groups
I20061003-0800 On the following test case, the compiler complains on X, contending that foo's return type is incompatible with I#foo, J#foo. This is wrong because X#foo has no parameter at all and cannot override J#foo. interface I { <T extends Exception & Cloneable> T foo(Number n); } interface J extends I { XX foo(Number n); } public abstract class X implements J { void foo() { } } abstract class XX extends Exception implements Cloneable {} Added AmbiguousMethodTest#32 (inactive) and 33.
The error is not about X#foo at all (even if its presence conditions the behavior). It is kicked by the compatibility check on methods inherited from different paths. On the following variant, adding a complete foo implementation on X solves the issue - which should not be needed: interface I { <T extends Exception & Cloneable> T foo(Number n); } interface J extends I { XX foo(Number n); } public abstract class X implements J { void foo() { } XX foo (Number n) { return null; } } abstract class XX extends Exception implements Cloneable {} On yet another source, javac and Eclipse agree that J and K are incompatible because their foo(Number) methods have incompatible types: interface I { <T extends Exception & Cloneable> T foo(Number n); } interface J extends I { XX foo(Number n); } interface K { NullPointerException foo(Number n); } public abstract class X implements J, K { } abstract class XX extends Exception implements Cloneable {} Changing the title accordingly and adding AmbiguousMethodTest#34.
The declaration of X#foo() is not needed to show the bug. Modified test32 accordingly.
Created attachment 52740 [details] Suggested fix + test cases modifications This patch essentially modifies MethodVerifier15#isInterfaceMethodImplemented by saying that a method which return type is merely compatible with the one of another method declared in a superinterface of its own declaring type can be considered as implementing the said method. All JDT Core tests pass, with a few differences in error messages though (which are also taken into account in the patch).
Created attachment 53361 [details] Fix + (some more) test cases modifications A few test cases changed in HEAD, catching up.
Released for 3.3 M4.
Verified for 3.3M4 with I20061211-1119
This fix appeared to break other cases (see bug 168331). The correction for this is quite more involving than I thought initially, and touches other areas as well (especially upper bounds), hence I reopen the bug for now.
Removed 3.3M4 target milestone.
Created attachment 57406 [details] Fix + test cases Incorporated Kent's advice + improved coverage. We do not cover the most general cases yet, but I would contend that we should reconsider the handling of existential types on a more general basis first. The current patch covers the original test case and a series of incremental variants around it. If more complex cases arise in real settings, we should be able to handle them on an on demand basis.
Released for 3.3 M5.
Verified for 3.3 M5 using build I20070206-0010
