Why does the compiler prefer an int overload to a varargs char overload for a char?

Code

public class TestOverload {

	public TestOverload(int i){System.out.println("Int");}
	public TestOverload(char... c){System.out.println("char");}
	
	public static void main(String[] args) {
		new TestOverload('a');
		new TestOverload(65);
	}
}

Output

Int
Int

Is it expected behaviour? If so, then why? I am expecting: char, Int

Note: I am using Java 8

Methods with varargs (...) have the lowest priority when the compiler determines which overloaded method to choose. Therefore TestOverload(int i) is chosen over TestOverload(char... c) when you call TestOverload with a single char parameter 'a', since a char can be automatically promoted to an int.

JLS 15.12.2 : > 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.

EDIT:

It you wish to force the compiler to call the TestOverload(char... c) constructor, you can pass to the constructor call a char[] :

new TestOverload (new char[] {'a'});

Yes, it is expected behaviour. The precedence for method calling goes like this :

1. Widending
2. Boxing
3. Varargs

Below is excerpt from Java docs related to same :-

>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: > > 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. > > 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. > >The third phase (§15.12.2.4) allows overloading to be combined with variable arity methods, boxing, and unboxing.

Solid advice from Joshua Bloch (Effective Java, 2nd Ed):

> "only choose as arguments for an overloaded method those that have -radically- different types."

An object with a radically different type is one that can not reasonably be cast into another of the argument types. Following this rule can potentially save you hours of debugging a mysterious error that can happen when the compiler chooses at compile time the method overloading that you did not expect.

Your lines of code violate this rule and open the door for bugs:

public TestOverload(int i){System.out.println("Int");}
public TestOverload(char... c){System.out.println("char");}

A char is interconvertible with an int and so the only way you can predict what will happen with the invocations is to go to the Java Language Specification and read the somewhat arcane rules about how overloadings are resolved.

Luckily, this situation shouldn't need JLS research. If you have arguments that are not radically different from each other, probably the best option is to not overload. Give the methods different names so that there is no possibility for error or confusion on the part of anyone who may need to maintain the code.

Time is money.

I took the code from this link and modified some parts of it:

    public static void main(String[] args) {
    Byte i = 5;
    byte k = 5;
    aMethod(i, k);
}

//method 1
static void aMethod(byte i, Byte k) {
    System.out.println("Inside 1");
}

//method 2
static void aMethod(byte i, int k) {
    System.out.println("Inside 2");
}

//method 3
static void aMethod(Byte i, Byte k) {
    System.out.println("Inside 3 ");
}

//method 4
static void aMethod(Byte  i, Byte ... k) {
    System.out.println("Inside 4 ");
}

The compiler gives error (The method is ambiguous for the type Overloading) for methods 1, 2 and 3 but not 4 (why?)

The answer lies in the mechanism which java uses to match method calls to method signatures. The mechanism is done in three phases, in each phase if it finds matching method it stops:

+phase one: use widening to find matching method (no matching methods found)

+phase two: (also) use boxing/unboxing to find matching method (method 1,2 and 3 match)

+phase three: (also) use var args (method 4 matches!)