Bug 159711 - [1.5][compiler] wrongly reports ambiguous method error
Summary: [1.5][compiler] wrongly reports ambiguous method error
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.3 M3   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-04 08:08 EDT by Gernot CLA
Modified: 2006-10-30 14:13 EST (History)
0 users

See Also:

Attachments
Fix + test case (4.37 KB, patch)
2006-10-18 04:37 EDT, Maxime Daniel CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gernot CLA 2006-10-04 08:08:08 EDT 
The following sample code does not compile.
The error message reported in the main method is: "the method doSomething(Collection<?>) is ambiguous"

package com.neppert;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.List;
import java.util.RandomAccess;

public class TestOverloads {
	public static void doSomething(Collection<?> collection) {
	}
	
	public static <C extends List<?>> void doSomething(C list) {
	}
	
	public static void main(String[] args) {
		doSomething(new ArrayList<String>(Arrays.asList("hallo")));
	}
}
Comment 1 Frederic Fusier CLA 2006-10-04 09:14:24 EDT 
I verified that using JDK 1.5.0_08, javac does not complain on this code...
Comment 2 Maxime Daniel CLA 2006-10-16 07:17:34 EDT 
Reproduced with HEAD. According to JLS 15.12.2, the second method is strictly more specific than the first one, hence maximally specific, and being the sole method to be maximally specific, it is the most specific method, and the call is not ambiguous.
Added (inactive) test cases #23 and 24 to AmbiguousMethodTest.
Comment 3 Maxime Daniel CLA 2006-10-17 10:28:04 EDT 
We rawify a bit too aggressively the parameters in ParametrizedGenericMethodBinding#tiebreakMethod in the case of a static method. A first attempt to fix that failed in the cases where the caller was already rawified. Currently testing less an agressive approach (using the upper bounds to build a parametrized generic method to use as the tiebreak).
Comment 4 Maxime Daniel CLA 2006-10-18 04:37:00 EDT 
Created attachment 52197 [details]
Fix + test case

In case the considered method is static, we build a tiebreak method that does not rawify its arguments types.
Comment 5 Maxime Daniel CLA 2006-10-18 04:47:48 EDT 
Released for 3.3 M3.
Comment 6 Olivier Thomann CLA 2006-10-30 14:13:57 EST 
Verified for 3.3 M3 using warm-up build I20061030-0800