Java method overloading and varargs

Question

I am trying to understand method overloading, and I have these methods.

public void method(int a){
    System.out.println("int a");
}

//implementing interface method
@Override
public void method() {
    System.out.println("interface");
}

//varargs
public void method(int ... a){
    System.out.println("int ... a");
}

After calling them with these parameters,

int[] a = new int[5];
stack.method();
stack.method(1);
stack.method(5,6);
stack.method(null);
stack.method(a);

I have these results:

interface
int a
int ... a
int ... a
int ... a

As far as I know, the program should not compile, beacuse of ambiguity, but it does anyway. Shouldn't the compiler throw an error?

Answer 1

Eran and Bathsheba have already said why the various ones not using null were chosen.

The rest of the question is: Why does stack.method(null); even compile?

The answer is that it matches the varargs signature, because the varargs method(int...) is effectively the same from the compiler's perspective as method(int[]). Since arrays are referenced by references, null can be used where an int[] is expected.

So:

stack.method();

Exact match for the method() signature in the interface. Not ambiguous with method(int...) because varargs are considered only when others don't match.

stack.method(1);

Matches method(int). Not ambiguous for the same reason as above.

stack.method(5,6);

Matches method(int...) because none of the non-varargs ones matched, but the varargs one did.

stack.method(null);

See earlier explanation.

stack.method(a);

Matches match(int...) for the same reason method(null0 does: Because match(int...) is effectively the same as match(int[]) to the compiler.

Answer 2

Method overloading resolution has three stages. The first and second stages don't consider methods with varargs (also called variable arity methods) as candidates, so only if no matching method without varargs is found, the compiler considers method with varargs as candidates.

Therefore, in the first and second method calls, your void method(int ... a) is ignored, and there is no ambiguity.

15.12.2. Compile-Time Step 2: Determine Method Signature

The second step searches the type determined in the previous step for member methods. This step uses the name of the method and the argument expressions to locate methods that are both accessible and applicable, that is, declarations that can be correctly invoked on the given arguments.

There may be more than one such method, in which case the most specific one is chosen. The descriptor (signature plus return type) of the most specific method is the one used at run time to perform the method dispatch.

A method is applicable if it is applicable by one of strict invocation (§15.12.2.2), loose invocation (§15.12.2.3), or variable arity invocation (§15.12.2.4).

Certain argument expressions that contain implicitly typed lambda expressions (§15.27.1) or inexact method references (§15.13.1) are ignored by the applicability tests, because their meaning cannot be determined until a target type is selected.

Although the method invocation may be a poly expression, only its argument expressions - not the invocation's target type - influence the selection of applicable methods.

The process of determining applicability begins by determining the potentially applicable methods (§15.12.2.1).

The remainder of the process is split into three phases, to ensure compatibility with versions of the Java programming language prior to Java SE 5.0. The phases are:

1. The first phase (§15.12.2.2) performs overload resolution without permitting boxing or unboxing conversion, or the use of variable arity method invocation. If no applicable method is found during this phase then processing continues to the second phase. This guarantees that any calls that were valid in the Java programming language before Java SE 5.0 are not considered ambiguous as the result of the introduction of variable arity methods, implicit boxing and/or unboxing. However, the declaration of a variable arity method (§8.4.1) can change the method chosen for a given method method invocation expression, because a variable arity method is treated as a fixed arity method in the first phase. For example, declaring m(Object...) in a class which already declares m(Object) causes m(Object) to no longer be chosen for some invocation expressions (such as m(null)), as m(Object[]) is more specific.

2. The second phase (§15.12.2.3) performs overload resolution while allowing boxing and unboxing, but still precludes the use of variable arity method invocation. If no applicable method is found during this phase then processing continues to the third phase. This ensures that a method is never chosen through variable arity method invocation if it is applicable through fixed arity method invocation.

3. The third phase (§15.12.2.4) allows overloading to be combined with variable arity methods, boxing, and unboxing.