Bug 73971 - [1.5] Ambiguous method error with overloaded parameterized methods
Summary: [1.5] Ambiguous method error with overloaded parameterized methods
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M4   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-15 05:58 EDT by Markus Keller CLA
Modified: 2004-12-14 15:40 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2004-09-15 05:58:21 EDT
I200409140800

The second and third call to m(..) yield wrong errors. After erasure, there's no
ambiguity, since the three methods m(..) are distinct. Maybe connected to bug 73970.

public class X {
    static <E extends A> void m(E e) { System.out.println("A:"+e.getClass()); }
    static <E extends B> void m(E e) { System.out.println("B:"+e.getClass()); }
    static <E extends C> void m(E e) { System.out.println("C:"+e.getClass()); }

    public static void main(String[] args) {
        m(new A());
        m(new B()); //error: "The method m(B) is ambiguous for the type X"
        m(new C()); //error: "The method m(C) is ambiguous for the type X"
    }
}

class A {}
class B extends A {}
class C extends A {}

javac 1.5.0-beta3-b62 compiles it and prints:
A:class q.A
B:class q.B
C:class q.C
Comment 1 Kent Johnson CLA 2004-11-19 15:48:29 EST
Philippe - This is a bug in ParameterizedGenericMethodBinding 
computeCompatibleMethod()

When the message send is m(new B()) and we substitute for the method:
   <E extends A> void m(E e)
we create a ParameterizedGenericMethodBinding:
   m(B)
instead of:
   m(A)

So we get 2 ParameterizedGenericMethodBindings with B as their substituted 
parameter instead of one with A & one with B.

Added MethodVerifyTest.test016()
Comment 2 Philipe Mulet CLA 2004-11-21 09:32:27 EST
Type inference is not meant to substitute parameters with their bounds, but
rather  with type inferred from argument types.

In this case, both (A)m(E) and (B)m(E) are substitutable into: m(B), which
causes the ambiguity in the end.

I suspect the tiebreak should use original methods rather than substituted ones,
or at least have original bounds play.
Comment 3 Philipe Mulet CLA 2004-11-22 07:02:25 EST
Tuned tiebreak. Added regression tests: GenericTypeTest#test425--426.
Fixed
Comment 4 Olivier Thomann CLA 2004-12-14 15:40:11 EST
Verified in 200412140800