Community
Participate
Working Groups
Observed this while verifying bug 357958. ######### class A { <T extends CharSequence & Serializable> void foo(T t) {} } class B extends A { <T extends Serializable & CharSequence> void foo(T t) {} } ######## foo in B overrides A but the override annotation doesn't appear. Note that there is no warning or error if @Override annotation is added to foo() in B. Also for the following case, Open declaration on super.foo works ok. class B extends A { <T extends Serializable & CharSequence> void foo(T t) { super.foo(t); } }
(In reply to comment #0) > foo in B overrides A but the override annotation doesn't appear. What do you mean? Should the annotation appear by itself? > Note that there is no warning or error if @Override annotation is added to > foo() in B. Because the override annotation is correct. This is what I see: - I get a warning on B#foo() that it is missing the @Override annotation. (Note that this warning is disabled by default.) - Using the quickfix I can add the annotation and the warning goes away. Satyam, I do not see a bug here.
> foo in B overrides A but the override annotation doesn't appear. Here, "annotation" refers to the override annotation that is shown in the vertical ruler of the editor (not the @Override). However, the ruler annotations are correct. The example actually reveals a bug in the Eclipse compiler: According to the spec, B#foo(T) does not override A#foo(T), since the erasures of the methods are different. This snippets shows the differences and prints the erasures of the called methods: package p; import java.io.Serializable; public class A { public static void main(String[] args) { A a= new B(); a.foo("1"); } <T extends CharSequence & Serializable> void foo(T t) { System.out.println("A#foo(CharSequence)"); //$NON-NLS-1$ } } class B extends A { // <T extends CharSequence & Serializable> void foo(T t) { // super.foo(t); // System.out.println("B#foo(CharSequence)"); //$NON-NLS-1$ // } <T extends Serializable & CharSequence> void foo(T t) { System.out.println("B#foo(Serializable)"); //$NON-NLS-1$ } } If you uncomment the first method in B, you also get a wrong compile error from the Eclipse compiler.
(In reply to comment #2) Yup these look like bugs. Both cases reported above contradict javac7 behaviour
(In reply to comment #2) > > foo in B overrides A but the override annotation doesn't appear. > > Here, "annotation" refers to the override annotation that is shown in the > vertical ruler of the editor (not the @Override). doh! :(
(In reply to comment #2) I see that while running the program. javac7 doesn't report the error if I have an override annotation. I thought that is the validation, should have run the program:( - Thanks.
Hi Satyam ! Sorry, I haven't had time at all to look at this, too busy with Java 8 work. Reverting to inbox to allow someone else to investigate
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Re-testing the program from comment 2 as shown: compile with javac8 and run: A#foo(CharSequence) compile with ecj (4.4.2-4.12M3) and run: B#foo(Serializable) compile with javac9 and run: B#foo(Serializable) I'm not sure what exactly happened, but by now javac and ecj agree. Uncommenting the first foo() in B: compile with javac (any version): A.java:19: error: method <T>foo(T) is already defined in class B compile with ecj (any version): 1. ERROR in /tmp/A.java (at line 14) Name clash: The method foo(T) of type B has the same erasure as foo(T) of type A but does not override it => Similar error but reported at different locations. Compiling with only the first foo() in B: both compilers accept and output when run is identical. ===> Only difference is in how we report the error in the middle case. WORKSFORME (resp. javac got fixed).
Verified 4.12 M3 using build I20190522-1800
