Summary: | [1.5][compiler] inconsistent @Override error | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tom Hofmann <eclipse> |
Component: | Core | Assignee: | Kent Johnson <kent_johnson> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | markus.kell.r |
Version: | 3.1 | ||
Target Milestone: | 3.1.2 | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: |
Description
Tom Hofmann
2005-09-05 06:07:17 EDT
This indeed feels inconsistent. These are the errors I get from javac (same as eclipse): X.java:16: foo(T) in Sub2 cannot override foo(E) in Sup1; attempting to use incompatible return type found : java.lang.Object required: T Object foo(T arg0) { // m1 ^ X.java:15: method does not override a method from its superclass @Override ^ 2 errors This PR is the same spec issue as bug 105808 so we'll track it there. *** This bug has been marked as a duplicate of 105808 *** Comment 0 is discussed in http://forum.java.sun.com/thread.jspa?threadID=659964 , and it looks like it's a spec bug and eclipse should wait with changing the compiler until that issue has been resolved. I don't think it's too much connected to bug 105808 (which is just about the API method IMethodBinding#overrides(..)). This bug complains about a superfluous error for @Override when an overriding method does not meet all additional requirements. Below is a standalone example of "inconsistent @Override error". That javac flags Sub#foo()'s @Override with "method does not override a method from its superclass" is just as wrong as eclipse's "The method foo() of type Sub must override a superclass method". Sub#foo() *does* override according to JLS3 ยง8.4.8.1. Therefore, there should not be any error for the @Override annotation. A similar case (but here, both compilers are correct) is given in SubException: SubException#foo() does override, but does not fulfill the additional requirements. Therefore, @Override is OK and the invalid exception is correctly flagged as error. class Top { Integer foo() { // m2 return null; } } class Sub extends Top { @Override Object foo() { // m1 return null; } } class SubException extends Top { @Override Integer foo() throws IOException { //m1 return null; } } Ok - we'll wait for resolution of http://forum.java.sun.com/thread.jspa? threadID=659964 OK, so you agree with the main issue of this bug (which was not the spec issue in the example from comment 0, but the wrong message from the @Override indication, as elaborated in comment 3)? I changed my mind. We will no longer complain about the @Override when the return types are not compatible while the parameters match. Chnaged several tests in MethodVerifer (see 27 & 44). Released into HEAD and the 3.1.2 branch Verified for 3.1.2 using build M20060109-1200. Verified for 3.2 M4 using build I20051215-1506. |