aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes overload method in boxing/unboxing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "overload method in boxing/unboxing" Watch "overload method in boxing/unboxing" New topic
Author

overload method in boxing/unboxing

reubin haz
Ranch Hand

Joined: May 12, 2005
Posts: 287
Resolution of overloaded methods selects the most specific method for execution.
here is an example of it:




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.


SCJA, SCJP5.0, SCBCD, SCWCD
Dave Wingate
Ranch Hand

Joined: Mar 26, 2002
Posts: 262
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.


Fun programming etcetera!
Joyce Lee
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392
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.


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



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?


Here is another example.


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:


Another example on overloading ambiguity from JLS3.

Just my 0.5 cents.

Joyce
[ July 01, 2005: Message edited by: Joyce Lee ]
reubin haz
Ranch Hand

Joined: May 12, 2005
Posts: 287
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
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392
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.



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):

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):


Same reasoning applies to the ColoredPoint example in JLS.



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

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


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


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


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.


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


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 ]
 
 
subject: overload method in boxing/unboxing