Bug 188960 - [1.5][compiler]Do not detect duplicate constructors in a ParameterizedType
Summary: [1.5][compiler]Do not detect duplicate constructors in a ParameterizedType
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.3 RC2   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-24 11:43 EDT by Kent Johnson CLA
Modified: 2007-05-25 20:41 EDT (History)
2 users (show)

See Also:
philippe_mulet: review+
Olivier_Thomann: review+


Attachments
Proposed patch (3.20 KB, patch)
2007-05-24 15:32 EDT, Kent Johnson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kent Johnson CLA 2007-05-24 11:43:28 EDT
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?
Comment 1 Kent Johnson CLA 2007-05-24 15:32:27 EDT
Created attachment 68657 [details]
Proposed patch
Comment 2 Kent Johnson CLA 2007-05-24 15:33:12 EDT
Philippe - this is fairly straight forward if you want to add it to 3.3 instead of 3.3.1
Comment 3 Philipe Mulet CLA 2007-05-25 04:49:27 EDT
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.
Comment 4 Philipe Mulet CLA 2007-05-25 04:56:27 EDT
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> {
}
Comment 5 Philipe Mulet CLA 2007-05-25 04:59:45 EDT
Re: comment 4
javac doesn't complain either about constructor collision...
Comment 6 Olivier Thomann CLA 2007-05-25 08:34:38 EDT
+1
Comment 7 Philipe Mulet CLA 2007-05-25 09:03:50 EDT
Let's try for rc2 then.
Kent - can you also add a test for comment#4 ?
Comment 8 Kent Johnson CLA 2007-05-25 09:50:52 EDT
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
Comment 9 Olivier Thomann CLA 2007-05-25 20:41:59 EDT
Verified for 3.3RC2 using I20070525-1350.