I have some trouble to understand which overloaded method is selected (or more specific) when the method is called, and when a method call is ambigious which results in "does not compile!". The simple cases are no problem but I want to give an example of an ambigious method call which looks like being not ambigious:
The first method looks to be more specific because three arguments can be mapped exactly to the parameter type int. The remaining argument can be mapped to an Interger by autoboxing, and the corresponding parameter type is the same in both methods. Unfortunatlely, the compiler says "The method meth(int, int, Integer, int) is ambigious for the type A". Why is it ambigious? When I replace all Integer parameter types with type long, the method call is no longer ambigious and the first method is called. Why that? Maybe the rules that I know are not complete, but I don't see why the one version is ambigious and the other is not.
Please go through the rules for disambiguating overloaded method calls in the Java® Language Specification (=JLS), and this JLS section. You cannot distinguish the potential signatures without boxing, bu tthere are two signatures both requiring boing. Are you going to box your ints, or are you going to widen them? That is the ambiguity. You could do either, so the compiler cannto find a better match using the procedure in those links.
posted 1 month ago
Hi Campbell Ritchie,
thank You for You efforts to help me to understand the reason for the ambiguity. Unfortunately, Your hints did not help me to understand the reason for the ambiguity at first glance. I read section 8.4.9 of the JLS, and I already knew what was presented there. I also read section 15.12.2 (second link) before I posted my question here in the forum. Luckily, I think that I now know the reason for the ambiguity, and the reason is a bit more complicated:
At first section 15.12.2 of the JLS tells me that in the first phase of the algorithm both methods are not applicable because boxing conversion is needed. In the second phase of the algorithm (188.8.131.52) both methods are accessible and applicable. Therefore the most specific method will be tried to find in section 184.108.40.206. There is used a binary relation <: which is defined in section 4.10 of the JLS. The relation is used to compare the parameter types of both methods whereat the first parameter type of method m1 is compared to the first parameter type of method m2, then the second parameter pairs are compared, and so on. Only if all parameter pairs fulfill the <: relation, method m1 is more specific than m2. Unfortunately, neither m1 is more specific than m2 nor is m2 more specific than m1. This is true, because the type int is not at all related to the boxing type Integer using the definition of the relation <: in section 4.10. Therefore, using the definition in section 220.127.116.11 both methods are maximally specific. When going forward to the end of that section the conclusion is that the method invocation is ambigious, and a compile time error occurs.
Summerizing the consideration the crucial point is that int and Integer are not related concering the <: relation and therefore the second parameter of both methods cannot be compared concerning <: and no method is more specific than the other => ambiguity! => compile time error!