Community
Participate
Working Groups
(Test case emerged out of bug 377146) The Eclipse compiler compiles the code below without compile problems, but the compiled code throws a ClassCastException at run time. Note that RenameMethod#m(Object) doesn't cleanly override C#m(T), but it overrides the erased method C#m(Object). Javac 1.7 reports this: RenameMethod.java:28: error: name clash: m(String) in Sub overrides a method whose erasure is the same as another method, yet neither overrides the other protected boolean m(String a) { ^ first method: m(Object) in RenameMethod second method: m(T) in C where T is a type-variable: T extends Object declared in class C ------ code: ------ class C<T> { // RENAME THIS METHOD (this method will be renamed) protected boolean m(T a) { System.out.println("C.m()"); return false; } } public class RenameMethod<T extends Object> extends C<T> { // RENAME THIS METHOD (this method will not be renamed) @Override protected boolean m(Object a) { // overrides the erased method! System.out.println("RenameMethod.m()"); return false; } public static void main(String[] args) { C<Object> c= new RenameMethod<Object>(); c.m(null); RenameMethod<String> rm = new Sub(); rm.m(new Object()); } } class Sub extends RenameMethod<String> { @Override protected boolean m(String a) { System.out.println("Sub.m()"); return false; } }
Yep, this seems to be a bug on our side. Srikanth, do you want me to investigate what it takes to fix this?
(In reply to comment #1) > Yep, this seems to be a bug on our side. > > Srikanth, do you want me to investigate what it takes to fix this? Thanks for the offer Stephan,
This one missed M1, rescheduling to M2.
Too late for M2.
With priority on Java 8 work I cannot promise a fix before M5. I hope that's OK.
Overriding erasures of generic methods is a mine field, nothing for last minute fixes into M5, sorry.
Still relevant in 1.8. Maybe JLS 8 helps to better understand what's needed here?
Ran out of time during Luna.
Preparation: rename <T> in RenameMethod to <U> for discrimination vs. <T> from C. Next: RenameMethod.m() indeed overrides C.m(). Error must be reported against Sub, indeed. I see no doubt about the intended behavior, so approaching this from the implementation p.o.v.: We want to report IProblem.MethodNameClash: Name clash: The method {0}({1}) of type {2} has the same erasure as {0}({3}) of type {4} but does not override it ProblemReporter.inheritedMethodsHaveNameClash() is the one which should be called in this case (both conflicting methods are inherited). One call from checkForBridgeMethod() should be irrelevant. Remains the chain MV15.checkMethods() -> MV15.checkInheritedMethods() -> MV15.detectInheritedNameClash() We don't reach the bottom of detectInheritedNameClash() because of the checks commented thusly: // skip it if otherInherited is defined by a subtype of inherited's declaringClass or vice versa. Removing these checks let's ecj report ---------- 1. ERROR in /tmp/RenameMethod.java (at line 26) class Sub extends RenameMethod<String> { ^^^ Name clash: The method m(T) of type C<T> has the same erasure as m(Object) of type RenameMethod<U> but does not override it ---------- GOAL. But: Failures in MethodVerifyTests after this modification: test145 - 1.5 test145 - 1.6 test145 - 1.7 test145 - 1.8 test342819 - 1.5 test342819 - 1.6 test342819 - 1.7 test342819 - 1.8 testBug411811 - 1.5 testBug411811 - 1.6 testBug411811 - 1.7 testBug411811 - 1.8 testBug415600 - 1.5 testBug415600 - 1.6 testBug415600 - 1.7 testBug415600 - 1.8 The checks had been added (2008) via commit c107fdebcaaafcbea0a28f68e9b229afba9f7c4f S.o. should probably analyse these failures and correlate to the bug numbers referenced in the commit: bug 236096 + bug 238014 + bug 238817.
Created attachment 270265 [details] experimental change for illustration
I went through some of these failures as well as a few in AmbiguousMethodTest and was surprised to find that in most of these cases, javac now reports a name clash error while our tests don't expect one (and fail because this change results in reporting the name clash). Makes me wonder if there was a javac bug all along. Back to the reading table with this one...
Bulk move out of 4.8
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
.
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.
