JDK-6199075 : Unambiguous varargs method calls flagged as ambiguous
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 5.0,6u22
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_suse_sles_9
  • CPU: generic,x86
  • Submitted: 2004-11-23
  • Updated: 2017-05-09
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b123Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
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
25-12-2010

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

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.
06-12-2010

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
23-11-2004