aspose file tools*
The moose likes Mock Exam Errata and the fly likes JQuest: String & StringBuffer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Mock Exam Errata
Bookmark "JQuest: String & StringBuffer" Watch "JQuest: String & StringBuffer" New topic
Author

JQuest: String & StringBuffer

yi miao
Greenhorn

Joined: Jun 29, 2001
Posts: 6
Question 28:
What is the result of attempting to compile the following program:
public class Test{
public void method(StringBuffer sb){
System.out.println("StringBuffer Version");
}
public void method(String s){
System.out.println("String Version");
}
public static void main(String args[]){
Test test=new Test();
test.method(null);
}
}
The answer is: Code does not compile, and compile error is reference to method is ambiguous.
However, in a piece of simliar code:
public class Test{
public void method(Object o){
System.out.println("Object Version");
}
public void method(String s){
System.out.println("String Version");
}
public static void main(String args[]){
Test test=new Test();
test.method(null);
}
}
This code works, and output is: String Version
I think for the first code, String & StringBuffer are two different string classes. "null" could be String or StringBuffer, so the compiler doesn't know which one it refer to. If we give a cast, then it should work. Am I right?
But for the second code, I really don't know why there is no compilation error, and why the output is String Version. I understand that Object is not a abstract class, so its instance could be null too. Anybody could tell me the trick here?
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
From the JLS:

15.12.2.2 Choose the Most Specific Method
If more than one method declaration is both accessible and applicable to a method invocation, it is necessary to choose one to provide the descriptor for the run-time method dispatch. The Java programming language uses the rule that the most specific method is chosen.
The informal intuition is that one method declaration is more specific than another if any invocation handled by the first method could be passed on to the other one without a compile-time type error.
The precise definition is as follows. 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.
A method is said to be maximally specific for a method invocation if it is applicable and accessible and there is no other applicable and accessible method that is more specific.
If there is exactly one maximally specific method, then it is in fact the most specific method; it is necessarily more specific than any other method that is applicable and accessible. It is then subjected to some further compile-time checks as described in �15.12.3.
It is possible that no method is the most specific, because there are two or more maximally specific methods. In this case:
If all the maximally specific methods have the same signature, then:
If one of the maximally specific methods is not declared abstract, it is the most specific method.
Otherwise, all the maximally specific methods are necessarily declared abstract. The most specific method is chosen arbitrarily among the maximally specific methods. However, the most specific method is considered to throw a checked exception if and only if that exception is declared in the throws clauses of each of the maximally specific methods.
Otherwise, we say that the method invocation is ambiguous, and a compile-time error occurs.

Wow! Neat and to the point. The JLS tells us that it will always choose the method with the parameters farther down the object hierarchy. If there's a tie, then no one wins and a compile time error occurs. Abstract classes always lose.
------------------
Tom - SCJP --- Co-Moderator of the Programmer Certification Forums
[This message has been edited by Thomas Paul (edited August 01, 2001).]


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JQuest: String & StringBuffer