JDK-7044388 : new varargs ambiguity error
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2011-05-12
  • Updated: 2011-05-16
  • Resolved: 2011-05-16
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
7Resolved
Related Reports
Relates :  
Description
The fix to 7042566(?) results in two methods such as
  void foo(int... ia) {}
  void foo(Object... oa {}
as now seen as both matching when foo is given two ints.
Test code:

public class test4 {
    public int foo(int ... vai)   { return 1; }
    public int foo(Object ... vaO) { return 2; }

    //TEST: choose best of overloaded methods
    public int test()    {
        int i1 = 1;
        int i2 = 2;
        int ret = foo(i1,i2);  //should choose method 1
        return ret;
    }

    public static void main(String[] args)    {
      test4 tv = new test4();
      System.out.println( tv.test()==1?"PASS":"FAIL" );
    }
}

Error message:
h:\ws\7_int\tools\src\javac\varargs\test4]javac test4.java
test4.java:18: error: reference to foo is ambiguous, both method foo(int...) in test4 and method foo(Object...) in test4 match
        int ret = foo(i1,i2);  //should choose method 1
                  ^
1 error

Comments
EVALUATION If we apply 15.12.2.5 literally, we have that: *) The parameters of the first method are 'int[]' *) The parameters of the first method are 'Object[]' *) arity of first method (n) == arity second method (k) == 1 *) "for all j from k to n, Tj <: Sk" - in this case, since the method in question is non-generic, this simply amounts as checking int <: Object. Now, since the spec use straight subtyping (i.e. no boxing conversion) - this yields false. Which means that m(int...) is *not* more specific than m(Object...); Other way around: *) The parameters of the first method are 'Object[]' *) The parameters of the first method are 'int[]' *) arity of first method (n) == arity second method (k) == 1 *) "for all j from k to n, Tj <: Sk" - in this case, since the method in question is non-generic, this simply amounts as checking Object <: int. There's clearly no way this could possibly hold. Hence, no method is most specific than the other - this should be an error.
16-05-2011