Java overloading: reference to call ambiguous

Question

Consider the following example code:

public class TestClass {

    public void doSth(String str, String l, Object... objects) {
        System.out.println("A");
    }

    public void doSth(String str, Object... objects) {
        System.out.println("B");
    }

}

When I now call new TestClass().doSth("foo", "bar") I get the expected result A. But if I change the method signature of the first method by chaging the parameter l to a primitive type:

public class TestClass {

    public void doSth(String str, long l, Object... objects) {
        System.out.println("A");
    }

    public void doSth(String str, Object... objects) {
        System.out.println("B");
    }

}

calling new TestClass().doSth("foo", 2L) will yield a reference to call ambiguous compile time error.

I thought about that one for some time now and also consulted this stackoverflow question, but I was unable to understand why this happens. In my opinion the doSth("foo", 2L) is more specific to the doSth(String string, long l, Object... obj) signature and should allow the compiler to also come to this conclusion.

Christinchristina

Evidently primitives can also be Objects? – Unilobed

@blahfunk, yes, they may be wrapped – Hollerman

The only explanation that comes to mind is Autoboxing, but this should be one conversion-step "farther" away than the primitive version of the method. – Aurora

I have no idea, but changing long to Long in the function declaration solved it for me. – Ivers

Looks like a duplicate of #17633241: the methods contains varargs arguments and the compiler needs to get to the third phase trying to distinguish between them – Polston

Answer 1

In this case, auto-boxing is causing you grief. Ironically, before that you're correct - the "long" version would have easily been picked.

Basically the compiler knows that it can create a Long from your value which, of course, is an Object. So it is still confused as either the long or the Long version could be used. Is one "better" than the other? Maybe but it is a pretty fine line.

Calabresi

Well, phase 1 in the JLS explicitely specifies performs overload resolution without permitting boxing or unboxing conversion. In this phase, autoboxing is not done. It looks like doSth(String str, long l, Object... objects) should be chosen in that phase. Am I missing something? – Polston

This is funny. Why does this not cause havoc, when there is only one parameter, i.e. doSth(long l) and doSth(Object o)? – Aurora

@Polston Phase 1 and 2 also exclude variable arity methods so neither of OP's methods are considered until phase 3. Curiously, doSth("foo", 2L, null) will compile because of what the italicized note under the 1st bullet (in your link) states. – Phalanstery

Answer 2

At this state, I can only report my observation, not the exact argumentation as to WHY Java behaves, like it does.

First, changing the methods to

void doSth(long l) {...}
void doSth(Object o) {...}

gets rid of the problem, i.e. doSth(2L); will yield the expected result.

Going one step further, changing the method parameter to varargs

void doSth(long... ls) {...}
void doSth(Object... os) {...}

together with the call doSth(2l); yields the same compilation error as reported by OP.

My suggestion at this stage is that encapusalting the parameter into an array, together with Autoboxing causes the havoc. My knowledge about the JLS is not firm enough to explain this properly.

Aurora