• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Overloaded Method Invocation Rules  RSS feed

 
Greenhorn
Posts: 5
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 64172
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

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.
 
Roland Heinrich
Greenhorn
Posts: 5
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 (15.12.2.3) both methods are accessible and applicable. Therefore the most specific method will be tried to find in section 15.12.2.5. 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 15.12.2.5 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!
 
Campbell Ritchie
Marshal
Posts: 64172
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well done working the subtyping rules out
 
We've gotta get close enough to that helmet to pull the choke on it's engine and flood his mind! Or, we could just read this tiny ad:
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!