JDK-8132544 : Compiler method binding error on overloaded method when varargs is present
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u51,9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: os_x
  • CPU: x86
  • Submitted: 2015-06-16
  • Updated: 2015-08-28
  • Resolved: 2015-08-27
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Darwin Brick-o-Matic.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64

A DESCRIPTION OF THE PROBLEM :
The javac compiler fails to correctly bind to one of multiple versions of an overloaded method whenever the overloaded method signatures have varargs. This worked fine in version 1.8.0_05 and I can confirm it was broken in 1.8.0_25 and continues to be broken in version 1.8.0_45.

REGRESSION.  Last worked in version 8u5

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the code.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No compile errors
ACTUAL -
foo.java:3: error: reference to foo is ambiguous
    foo(true, "hello");
    ^
  both method foo(Object,String,Object...) in foo and method foo(boolean,String,Object...) in foo match
1 error

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class foo {
  public static void main(String... args) {
    foo(true, "hello");
  }

  public static void foo(Object o, String string, Object... args) {
  }

  public static void foo(boolean b, String string, Object... args) {
  }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Change varargs to an array on the method signature or rename one of the methods to not make them overloaded. This is difficult when using libraries that we don't have control over.


Comments
The behavior of most specific check was overly loose (and not compliant with the spec) when JDK 8 was released; this has then been fixed in JDK-8034223.
27-08-2015

This is not an issue - overload resolution is structured in three steps: 1 strict subtyping check - in this phase a method is applicable only if actual arguments are subtype of formals 2 boxing check - in this phase a method is applicable if there exist a conversion from actuals to formal - this can include boxing 3 varargs check - this phase is similar to the boxing check, except that it onlyapplies to varargs method, whose signatures are 'expanded' so as to fit the actual arguments arity In the above example, both 1 and 2 fail - as we are attempting to pass 2 arguments to a method accepting 3 (these two steps are varargs-agnostic). The third step kicks in, and, according to the rules in this step, both methods are applicable (one is via boxing, the other via subtyping). Most specific rules can't pick a best method, as neither boolean is a subtype of Object nor vice-versa. While most specific rules have been enhanced to take into account actual argument types - such enhancement only applies when the actual argument expression is either a lambda, a method reference, a conditional (i.e. poly expressions) - see JLS 15.12.2.5.
27-08-2015

JDK version information in the description appears incorrect when compared to the results I observed. I have written to the submitter to confirm the actual based upon above comment.
27-08-2015

This error is reproducible with JDK 7u85, 8u51, 8u60 ea b24, and 9 ea b73. The code compiles fine with JDK 8u45. =================================================================== 8: OK 8u45: OK 8u51: FAIL 8u60 ea b24: FAIL 9 ea b73: FAIL Output with JDK 8u51: > javac foo.java foo.java:3: error: reference to foo is ambiguous foo(true, "hello"); ^ both method foo(Object,String,Object...) in foo and method foo(boolean,String,Object...) in foo match 1 error ======================================================================= Sent an email to the submitter requesting confirmation of above results.
27-08-2015

Pardeep, reproduce the issue.
22-06-2015