This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Originally posted by Harjinder Singh: Hi Pals, What will be the putput of this code?
Now if i changed this to sumthing like this, then what will happen?
Can anyone explain the reasons behind it?
Hi Harjinder, In your 1st example, the output would be "String Version" because it is that method that is most specific. For you 2nd example, I believe you will get a compiler error because none of the methods are most specific. From the JLS:
Let m be a name and suppose that there are two declarations of methods named m , each having n parameters. Suppose that one declaration appears within a class or interface T and that the types of the parameters are T1, . . . , Tn; suppose moreover that the other declaration appears within a class or interface U and that the types of the parameters are U1, . . . , Un. Then the method m declared in T is more specific than the method m declared in U if and only if both of the following are true: " T can be converted to U by method invocation conversion. " Tj can be converted to Uj by method invocation conversion, for all j from 1 to n.
and the null reference can always be cast to any reference type.
Hi Harjinder! The first question will print "String Version". The second one will give a compiler error complaining of ambiguous reference. In case of overloaded methods, when an argument can possibly be assigned to different methods according to their heirarchy of the parameter, then that method is called into play which provides the narrow most reference to the argument. For example in your case, one parameter is of type Object and the other of String. And we know that a String is subclass of Object. So null, which normally is assignable to both Object or String, will be taken up by the method with String parameter as it is a more specific reference to null. And if U do away with the Object and put in a StringBuffer parameter, the compiler cries foul rather than "putputting" sth, because String and StringBuffer are equally narrow in their reference to null. The compiler is unable to decide which of the two overloaded methods will take up the call. I would suggest that to get a more clear perspective on this issue, rather than using a String or StringBuffer, create your own classes in a Single Inheritence and use their type of variables to refer to null Sth like :
So this will SubClass Version as output, as SubClass is a narrower refernce to SuperClass And if U have sth like the following :
This will give a compiler error.. as SubClass and SubClass2 are sibling classes and the compiler is confused between which to choose?? I hope things are clearer? Cheers Anupreet
Joined: May 02, 2001
Thanks mate, yeps they are pretty clear now... Thanks all of you guys and i must say that Javaranch is the coolest place to be in.. i just love this place...