Community
Participate
Working Groups
I20050726-1222 (already a problem in 3.1) IMethodBinding#overrides(..) should not consider return types. According to JLS3 §8.4.8.1, only method signatures are considered for the override check. class Top { Integer m() { return 1; } } class Sub extends Top { @Override Object m() { // overrides Top#m(), in spite of the compile error return null; } }
MethodVerifier#doesMethodOverride(...) takes the return types into account. Need to check with Philippe (when he's back) if this is intended.
Created attachment 26522 [details] Regression test
Kent, could you please move this bug back to me once you've provided a method that doesn't consider return types ?
do you need this in 3.1.1 or just 3.2?
Not needed for 3.1.1.
I just tried this testcase with javac and I got the following errors: X.java:9: m() in Sub cannot override m() in Top; attempting to use incompa tible return type found : java.lang.Object required: java.lang.Integer Object m() { // overrides Top#m(), in spite of the compile error ^ X.java:8: method does not override a method from its superclass @Override ^ So can someone tell me why we should ignore return types ?
*** Bug 108782 has been marked as a duplicate of this bug. ***
The case from bug 108782: class Sup2<E> { E foo(E e) { // m2 return null; } } class Sub2<T> extends Sup2<T> { @Override Object foo(T arg0) { // m1 return null; } } Also related to bug 108780, where the case is: class Sup1<E> { E foo(E e) { // m2 return null; } } class Sub1<T> extends Sup1<T> { @Override T foo(Object arg0) { // m1 return null; } }
(In reply to comment #6) > I just tried this testcase with javac and I got the following errors: > > X.java:9: m() in Sub cannot override m() in Top; attempting to use incompa > tible return type > found : java.lang.Object > required: java.lang.Integer > Object m() { // overrides Top#m(), in spite of the compile error > ^ > > X.java:8: method does not override a method from its superclass > @Override > ^ > > > So can someone tell me why we should ignore return types ? javac checks if the m() in Sub overrides m() in Top AND if the return types are compatible (as we do in the compiler). Here we just ask you to extract the overrides() part.
Kent, to give you some context: JDT/UI currently uses their own overrides tests for the override indicator and for quick fixes. We'd like to switch to the JDT/Core API, but we can only do so if we don't lose functionality. IMethodBinding#overrides(..) should adhere to the spec in JLS3, which does not consider return types. Since Sub#m() overrides Top#m(), we e.g. want to show an override indicator. That the compiler issues error messages is irrelevant for us in this case.
So let me get this straight... You want a method #overrides() that answers true when the compiler generates an error saying it doesn't? Does that make sense to anyone?
I interpret the compiler message as follows: It says that Sub#m() DOES override Top#m() BUT its return type is incompatible, so this is not allowed. Are YOU saying that the compiler doesn't follow JLS3 §8.4.8.1 ? ;-)
(In reply to comment #11) > You want a method #overrides() that answers true when the compiler generates > an error saying it doesn't? What compiler message are you talking about? The eclipse compiler issues two errors: 1. "The return type is incompatible with Top.m()" -> Does not exclude in any way that Sub#m() overrides Top#m(). 2. "The method m() of type Sub must override a superclass method" -> This is wrong and the subject of bug 108782. The error messages that javac generates are of minor importance for me ...
Ok, we'll change the existing method #doesMethodOverride in the MethodVerifier. I'm also changing the behaviour of the override error, we will no longer report it if the methods are equal, but their return types are not.
Changed the existing method MethodVerifier#doesMethodOverride() Also see bug 108782 for the override error issue. Released into HEAD and the 3.1.2 branch
Released regression test from comment 2 (renamed to test032()) in both HEAD and R3_1_maintenance branch.
Verified for 3.1.2 using build M20060109-1200.
Verified for 3.2 M4 using build I20051215-1506.