Community
Participate
Working Groups
M20050831-1200 Consider below snippet. --------- SubSup.java ---------- class Sup2<E> { E foo(E e) { // m2 return null; } } class Sub2<T> extends Sup2<T> { @Override Object foo(T arg0) { // m1 return null; } } -------------------------------- - m1's signature clearly is a subsignature of m2, hence m1 overrides m2. - this is supported by - the compiler warning ("the return type is incompatible") - the override indicator - no "name clash" error - However, there is also an error that m1 "must override a superclass method" stemming from the '@Override' annotation. I think that no matter whether the return type is or is not compatible, the @Override annotation is correct and should not be flagged, since m1 does indeed override m2. Notes: - javac shows the same behavior (flags @Override with "method does not override a method from its superclass") - whether the m1 is return-type-substitutable to m2 or not is not clear to me, since Object = |E| (see 8.4.5). However, this is both flagged by javac and eclipse and may be a spec issue. Markus has raised the issue on another mailing list.
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.
