United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6199075 Unambiguous varargs method calls flagged as ambiguous
6199075 : Unambiguous varargs method calls flagged as ambiguous

Details
Type:
Bug
Submit Date:
2004-11-23
Status:
Closed
Updated Date:
2011-06-04
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
tools
OS:
linux_suse_sles_9,generic
Sub-Component:
javac
CPU:
x86,generic
Priority:
P5
Resolution:
Fixed
Affected Versions:
5.0,6u22
Fixed Versions:
7

Related Reports
Backport:
JDK-2203535 - Unambiguous varargs method calls flagged as ambiguous
Duplicate:
JDK-6558474 - Var args and most specific
Duplicate:
JDK-6998691 - Vararg method overloading fails
Relates:
JDK-7013865 - varargs: javac crashes during overload resolution with generic varargs
Relates:
JDK-6886431 - Handling of "most specific" varargs method inconsistent with JLS
Relates:
JDK-5088429 - varargs overloading problem
Relates:
JDK-7042566 - Regression: new ambiguity between varargs method

Sub Tasks

Description
$ cat -n Test.java
     1  class Test {
     2      public static void foo(int ...i) {}
     3      public static void foo(double...d) {}
     4
     5      public static void main(String[] args) {
     6          foo(1, 2, 3);
     7      }
     8  }
     9
$ javac Test.java
Test.java:6: reference to foo is ambiguous, both method foo(int...) in Test and method foo(double...) in Test match
        foo(1, 2, 3);
        ^
1 error

Javac is incorrect since int <: double which makes foo(int...) more specific than foo(double...).

Comments
EVALUATION

http://hg.openjdk.java.net/jdk7/build/langtools/rev/b1c98bfd4709
2010-12-25 
SUGGESTED FIX

A webrev of this fix is available at the following URL:
http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b1c98bfd4709
2010-12-10 
EVALUATION

The problem is that the implementation of the most specific check w.r.t. varargs method is implemented in terms of checks involving array types, while the check described in the JLS is transparent w.r.t. array types. Consider the following two methods:

m(int...)
m(short...)

Now, if most specific is applied as implemented in the compiler, the two signatures become:

m(int[])
m(short[])

And, since primitive arrays are not covariant, we have that neither signature is more specific than the other (int[] cannot be applied where short[] is expected, nor viceversa).

The JLS check, on the other hand, reduces the above signatures to the following:

m(int)
m(short)

In which case is clear that m(short) is the most specific. Javac implementation should be changed accordingly.
2010-12-06 
EVALUATION

This is a compiler bug.  I expect the problem to be in the implementation
of most specific or the subtype relation.

###@###.### 2004-11-23 02:54:33 GMT
2004-11-23


Hardware and Software, Engineered to Work Together