Community
Participate
Working Groups
Copied from https://bugs.eclipse.org/bugs/show_bug.cgi?id=166355#c14 ----------------- My problem relates to calls to super(), where the call is ambiguous due to generics. Consider the classes: public class SuperClass<T> { public SuperClass(String _arg1) { System.out.println("String"); } public SuperClass(T _arg1) { System.out.println("T"); } } class SubClass<T> extends SuperClass<T> { public SubClass(String _arg1) { super(_arg1); } public SubClass(T _arg1) { super(_arg1); } } When I invoke "new SubClass<String>("xyz")", which constructor is invoked? javac takes the position that this is ambiguous, and will actually fail with a "reference to SuperClass is ambiguous..." message. It's hard to say, but it looks like Eclipse resolves this with "Last Match Wins". That is, it makes a list of both possible matches, and chooses the "last", based on the order the constructors appear in the class. This is not intuitive to me! However, I also don't think there exists an intuitive solution to this, and that's why I feel javac is right here in just not allowing this kind of call. A related example: class StringOnlySubClass extends SuperClass<String> { public StringOnlySubClass(String _arg1) { super(_arg1); } } In this case, 3.2 appears to use "First Match Wins", and 3.1 uses "Last Match Wins". Could this be added as a warning, if not an error?
Created attachment 68657 [details] Proposed patch
Philippe - this is fairly straight forward if you want to add it to 3.3 instead of 3.3.1
The fix looks good (actually exact same fix as for #getExactMethod). One nit in the patch, Kent, you introduce an extraneous semicolon (empty statement). I would take it for 3.3 since it is a trivial change.
Out of curiousity, why don't we also get a complaint for constructor collision, like we do for methods: In following case, no complaint is emitted against constructors, but are emitted against methods. class SuperX<T> { SuperX(String s) {} SuperX(T t) {} void foo(String s) {} void foo(T t) {} } public class X extends SuperX<String> { }
Re: comment 4 javac doesn't complain either about constructor collision...
+1
Let's try for rc2 then. Kent - can you also add a test for comment#4 ?
I saw the semicolons after I posted the patch. Added the additional test to show duplicate constructors do not report an error, but any call to them is reported as ambiguous. Released into HEAD for 3.3RC2
Verified for 3.3RC2 using I20070525-1350.