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.
[ June 26, 2005: Message edited by: reubin nibuer ]

[Marcelo Ortega]

hi reubin,

look carefully at your code.
take this signature from your code for instance:

flipFlop(String str, int i, Integer iRef)

it should be ...

flipFlop(String str, Integer iRef, int i)

changing that will compile, but if you comment it out, then in the call to the other method will cause a compile time error. in this case the call should be:

flipFlop("String Integer int", new Integer(4).intValue(), 2004); //good to go

hope this helps.

Cheers, Marzo.

[reubin haz]

Thank you for your reply, but

Originally posted by Marzo Kaahn:
it should be ...

flipFlop(String str, Integer iRef, int i)

changing that will compile,

Of course, change it to be like that would make it exactly match the calling statement.

Originally posted by Marzo Kaahn:

flipFlop("String Integer int", new Integer(4).intValue(), 2004); //good to g

change calling statement to this would make an exact match for the second overload method.

I should mention that I'm using JRE5.0, since it release us from memorizing wrapper classes.

I copied those code and explanation from http://java.boot.by/scjp-tiger/ch01s04.html
here
and I test it on my machine with JRE5.0. The compiler complains it.
So it still confuses me. Help please.

[Marcelo Ortega]

my point is that if you leave the code how you have it, the compiler cannot find a match, because new Integer(4), returns a reference, not a primative int, and the compiler cannot find a method signature with the second param being an object (in this case Integer).

Cheers, Marzo.

[reubin haz]

In JRE 5.0, 'new Integer(4)' can be automatically converted into primitive int type, and '200'4 can be automatically converted into Integer object.

So for the first overloaded method, 2 parameters need to be autoboxing/unboxing, for the second overloaded method, only the middle one needs to be converted. Therefore, the second method is more specific than the first one. Why does the compiler still complain it?

Thanks.

[reubin haz]

Originally posted by Marzo Kaahn:
my point is that if you leave the code how you have it, the compiler cannot find a match

if I only allow one overloaded method exists at a time, either of them will compile and run.