Rules for selection an overloaded method with multiple parameters in Java

Question

I know about overloading rules in Java, but for some situations my intuition doesn't work.

Let's consider an example:

public class Overloading {
    public static void main(String[] args) {
        long primitive = 3;
        Long boxed = Long.valueOf(5);
        doWork(primitive, boxed);     //1
        doWork(boxed, boxed);         //2
        doWork(primitive, primitive); //3                
    }

    static void doWork(Long a, Long b) {}

    static void doWork(long a, Long b) {} 
}

Do you know what (1, 2 or 3) will be compiled successfully?

The first and the second will, but third won't (due to ambitious method call).

Why is javac designed this way and can't resolve this situation? Why not to cast #3 to #1?

And which one of the implementations should Java choose for you ? That ambiguity is exactly the reason that the implementers chose to return an error. — Nir Alfasi, Sep 12 '13 at 15:17
See Related: http://stackoverflow.com/questions/501412/why-does-autoboxing-make-some-calls-ambiguous-in-java?rq=1 — Sotirios Delimanolis, Sep 12 '13 at 15:18
@alfasin I expected that java can choose an option with minimum possible autoboxing operations. I was wrong, the phrase: "Also: the compiler can't always choose the most specific method based on the number of auto(un)boxing needed." from the topic poited by Sotirios explains it. Thanks! — Dmitry P., Sep 12 '13 at 15:26

score 2 · Accepted Answer · edited May 23 '17 at 12:08

2

Good Question!

You're suggestion that #3 should be cast to #1 does seem to make sense, because it has one less auto-boxing to do.

This is probably the reasoning behind Java's decision to give you an error instead of picking the method with the least boxing involved:

This situation is rare.
Figuring out which method to use for auto-boxing could be expensive*.
The logic behind which method to choose could be too subjective.
Therefore, in this case, Java forces you to not be ambiguous.

*The accepted answer to the question linked to by Sotirios gives some insight into why it might by too expensive to be worth it.

edited May 23 '17 at 12:08

Community

1
1

answered Sep 12 '13 at 15:22

James Dunn

8,064
13
53
87

It does not have anything to do with the algo being expensive - it is mostly for backward compatibility reasons. – assylias Sep 12 '13 at 16:20
@assylias Good point about backward compatibility; for this reason Java would not want to change the rules in future versions. But it still begs the question about the original decision in Java 1.5 when this became an issue. – James Dunn Sep 12 '13 at 17:21

score 0 · Answer 2 · answered Sep 12 '13 at 15:21

0

The first and the second will, but third won't (due to ambidous method call). Why java can't resolve this situation? Why not to cast #3 to #1?

As you mentioned, long can be autoboxed to Long. However, there is an ambiguity here - if only the second long is autoboxed, you'd get #1. If both of them are autoboxed, you'd get #2.

Since Java cannot decide which method you meant, it raises an error.

answered Sep 12 '13 at 15:21

Mureinik

297,002
52
306
350

Theoretically, Java could have been designed to choose one of the methods over the other -- I think Dmitri's question was why it was not designed this way. – James Dunn Sep 12 '13 at 15:23

Rules for selection an overloaded method with multiple parameters in Java

2 Answers2