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 ]