• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
Bartenders:
  • Piet Souris
  • Jj Roberts
  • fred rosenberger

overloaded method

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Case 1


CASE2






CASE1: compiles correctly and prints "String version"


but CASE2: results on compile time error, "reference to method is ambiguous, both method method(java.lang.StringBuffer) in Test and method method(java.lang.String) in Test match
new Test().method(null);"


???
 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In first case your method() takes Object and String as parameter. Now btw these two the most specific is String version of the method. So if you invoke method(null) the most specific method will be chosen and method(String s) will be executed.
In second case you have method(String s) , method(StringBuffer s) now for the argument null both can be matched since null can be assigned to a reference of type string or to a reference of type StringBuffer and hence there is this ambiguity for method(null) , Even if you have
method(String s) {} and method(Integer i) {} and invoke method(null); still the code will not complie because now null can be assigned to method String and Integer and both are more specific versions.
However if you have method(String s){} and method(Object o){} and as you know null can be assigned to String or Object reference and since String version is more specific here when compared to Object version of method , the String version of method is invoked.
Hope this clears.
 
Ranch Hand
Posts: 274
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gurpreet,

In 1st case, the best match is String, though both String as well as Object can accept null.

In 2nd case both String and StringBuffer both are the best match which confuses the compiler hence the compilation error.
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah in short what Gitesh Ramchandani said
 
Ranch Hand
Posts: 3389
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This most specific method explains me clearly
 
Ranch Hand
Posts: 433
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Let me try to throw some lights on specific method :
lets go step by step :

Take the argument of both methods, Like in this case :
Object and String

check out the hirerachy :
Object ---> String
or
String is subclass of Object,

The most subclass is consider as most specific, so String version is called.

Case second :

Step 1: StringBuffer , String

Step 2: Object ----> StringBuffer
Object ----> String

Step 3: Since they come at same level of hirerachy,so call is ambigous.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic