Summary: | [compiler] extraneous interface compatibility error | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Maxime Daniel <maxime_daniel> | ||||||||
Component: | Core | Assignee: | Maxime Daniel <maxime_daniel> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | ||||||||||
Version: | 3.3 | ||||||||||
Target Milestone: | 3.3 M5 | ||||||||||
Hardware: | PC | ||||||||||
OS: | All | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Maxime Daniel
2006-10-24 09:20:28 EDT
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 |