Community
Participate
Working Groups
This is a FUP of bug 353089. It is a slight modification of the test given there. ### import java.util.*; interface A { int get(List<String> l); } interface B { int get(List<Integer> l); } interface C extends A, B { //int get(List l); // name clash error here } ######### Here, javac7 reports error, but javac5, javac6 and ecj doesn't. According to Srikanth, this is probably not a bug, because any class that implements C, could override 'get' with a raw type 'List'.
Here is another example which we compile alright and which javac7 doesn't: interface X { <T> T e(Action<T> p); } interface Y { <S, T> S e(Action<S> t); } interface E extends X, Y { } class Action<T> { } Per 8.4.2, this should not compile, since the two methods don't have the same signature, neither is a subsignature of another and so they are not override equivalent. But their erasure is the same and so should lead to a name clash error, but doesn't.
See that we complain for: interface X { <T> T e(Action<T> p); <S, T> S e(Action<S> t); }
(In reply to comment #0) > According to Srikanth, this is probably not a bug, because any class that > implements C, could override 'get' with a raw type 'List'. That is true, however, JSR335 EDR makes a point about this exact same scenario and makes a persuasive case that this should be an error the reasoning being generics aware code should not encourage use of raw types.
Fix and tests released via commit id: c36a6a2b662267e56067d121b7f34ae48cbcb692. (In reply to comment #0) > Here, javac7 reports error, but javac5, javac6 and ecj doesn't. Accordingly, we now report an error only for compliance level >= 7.
Verified for 3.8M5 using I20120122-2000 A question: The code specified in comment #2 still produces error in 1.5 and 1.6 compliance level. Is it because the JSR335 you were referring to doesn't include this case? The behavior is in line with Javac, though.
(In reply to comment #5) > Verified for 3.8M5 using I20120122-2000 > > A question: The code specified in comment #2 still produces error in 1.5 and > 1.6 compliance level. Is it because the JSR335 you were referring to doesn't > include this case? The behavior is in line with Javac, though. JSR 335 is futuristic (JDK8 plan item) and its reference is incidental here. i.e the code does not become legal/illegal on account of this JSR. I happened to mention only because, in the spec, there is a passing reference to some of the test cases in this bug (nearly identical ones). to develop some of the theme items of the JSR. Historically we have tried to maintain compatibility as also in this case. That should explain how the pre-existing behavior in comment#2 came about.
*** Bug 348377 has been marked as a duplicate of this bug. ***
