overload method in boxing/unboxing

[reubin haz]

Resolution of overloaded methods selects the most specific method for execution.
here is an example of it:

 
flipFlop("(String, Integer, int)", new Integer(4), 2004); // COMPILER ERROR!
...
 
private static void flipFlop(String str, int i, Integer iRef) {
out.println(str + " ==> (String, int, Integer)");
}
 
private static void flipFlop(String str, int i, int j) {
out.println(str + " ==> (String, int, int)");
} 
 

It explains that the method 'flipFlop(String, int, Integer)' is ambiguous

But I thought the second method flipFlop(String str, int i, int j) is more specific than the first one, since the second one need only convert one parameter type, while the first one requires two parameters to be converted. Why the compiler is still complaining?

Can someone explain this? Thanks.

[Dave Wingate]

Could this be a case where the compiler error message is less than helpful? I didn't think that java would do conversion from int to Integer (or vice versa). If that is true, then the method call could not really be applied to either of the methods you've defined.

[Joyce Lee]

Hi reubin,

Hmmm...I think maybe because when it comes to autoboxing/unboxing, neither flipFlop is more specific than the other.

Quote from Section 15.12.2.5 of JLS3:
-----------------------------------------------------
A method m1 is strictly more specific than another method m2 if and only if m1 is more specific than m2 and m2 is not more specific than m1.

A method is said to be maximally specific for a method invocation if it is accessible and applicable and there is no other method that is applicable and accessible that is strictly more specific.
-----------------------------------------------------

With autoboxing/unboxing, both flipFlop methods can accept any of the following argument combinations, thus none is more specific than the other.

flipFlop("Hello", 1, 1);
flipFlop("Hello", new Integer(1), 1);
flipFlop("Hello", 1, new Integer(1));
flipFlop("Hello", new Integer(1), new Integer(1));

Let's examine other examples that do not require autoboxing/unboxing.

processChar('a', 'b', 'c');
...
void processChar(char c1, int c2, int c3) { } 
void processChar(char c1, char c2, int c3) { } // this is chosen

There is no ambiguity for the compiler. Both processChar methods can handle this arguments combination: char, char, char. However, processChar(char, int, int) can accept more argument combination like the one as follows. Thus, that makes processChar(char, char, int) more specific. Make sense?

processChar('a', 1, 1); 

Here is another example.

processString("How", "are", "you");
...
processString(String s1, Object s2, Object s3) { }
processString(String s1, String s2, Object s3) { } // this is chosen

Again, no ambiguity occurs for the above example. Both processString methods have no problem handling arguments of this combination: String, String, String. As we can see, processString(String, Object, Object) can handle more different argument combinations, thus less specific:

processChar("Hello", new Integer(1), new Integer(1));

Another example on overloading ambiguity from JLS3.

Just my 0.5 cents.

Joyce
[ July 01, 2005: Message edited by: Joyce Lee ]

[reubin haz]

Thanks for your reply Joyce. From the examples you provided, the reason one method is more specific than another is because it requires less number of times to do implicit casting. So this caused me to think it's also true to apply this rule on auto boxing/unboxing -- it is more specific for a method that requires less number of times to do boxing/unboxing. But it seems I'm wrong, so can I conclude number of required boxing/unboxing does not acount for being more specific?

[Joyce Lee]

Hi reubin,

so can I conclude number of required boxing/unboxing does not acount for being more specific?

No, I don't think the number of required boxing/unboxing accounts for being more specific as we can see in the flipFlop example.

First, my previous explanation on the flipFlop example was vague and incorrect but the reasoning for the other examples still holds. Let me try explaining the flipFlop example again and see if that makes sense to you. Please do refer to JLS3 chapter 15 for verification.

Quote from Section 15.12.2.5 of JLS3:
-----------------------------------------------------
A method m1 is strictly more specific than another method m2 if and only if m1 is more specific than m2 and m2 is not more specific than m1.
-----------------------------------------------------

Let's have a common understanding of what is meant by "more specific". To me, m1 is more specific if m2 can handle whatever combinations m1 can and "more" but not vice versa. If both m1 and m2 have certain combination that the other cannot handle, then ambiguity arises. My conclusion is based mainly on my observation of the compiler's behavior rather than the JLS3. IMO, JLS3 doesn't seem to provide a clear explanation on this aspect. Well, if I miss out some vital info, please do share it here, thanks.

According to 15.12.2.2 and 15.12.2.3 of JLS3, the compiler will first see if there's a match without considering autoboxing/unboxing in phase 1. If the searching fails, the compiler moves on to phase 2.

flipFlop("(String, Integer, int)", new Integer(4), 2004); 
...
private static void flipFlop(String str, int i, Integer iRef) { }
 
private static void flipFlop(String str, int i, int j) { } 

Apparently, the compiler is in the phase 2 of searching a suitable flipFlop method since without autoboxing/unboxing, the compiler can't find a suitable flipFlop in phase 1. Both flipFlop can handle the combination: "Hello", new Integer(2), 2004. Now, the compiler needs to determine which is more specific. "Unfortunately", neither one is more specific than the other because both can handle certain combination that the other one cannot.

The following combination can only be handled by flipFlop(String, int, new Integer):

flipFlop("Hello", 1, any subclass of Integer)

OK, we know that Integer is a final class so no subclassing is allowed. However, based on my observation, the compiler doesn't seem to care if the class type is final or not. If the "final" is taken into consideration, I would say flipFlop(String s, int i, Integer) is more specific.

The following combination can only be handled by flipFlop(String, int, int):

flipFlop("Hello", 1, 'a');

Same reasoning applies to the ColoredPoint example in JLS.

ColoredPoint cp = new ColoredPoint();
test(cp, cp);     
...
static void test(ColoredPoint p, Point q) { ... }
 
static void test(Point p, ColoredPoint q) { ... } 

Both test methods can handle the combination test(new ColoredPoint(), new ColoredPoint()).

However, only test(ColoredPoint, Point) can handle the following combination:

test(new ColoredPoint(), any subclass of Point);

And only test(Point, ColoredPoint) can handle the following combination:

test(any subclass of Point, ColoredPoint);

Here is another example (no autoboxing/unboxing) that causes ambiguity.

test('a', 1, 'a', 'a');
...
static void test(int w, int x, char y, char z) { } // line 1
  
static void test(char w, int x, long y, long z) { } // line 2 

Notice that the one at line 1 has a higher number of matching parameter types, but still, ambiguity occurs. Reason?
Only test(int, int, char, char) can handle the first argument with int type.

test(1, 1, 'a', 'a');

Only test(char, int, long, long) can handle the following combination:

test('a', 1, 123L, 123L); 

Thus, none of the test method is more specific than the other.

That's all for now.

Joyce
[ July 02, 2005: Message edited by: Joyce Lee ]