Overload Resolution: Interpretation of the Null Literal
In Java, a null literal is a valid reference that can be assigned to any object variable, including those of reference types like String. This behavior plays a crucial role in resolving overloaded methods when a parameter is passed as null.
Consider the following code snippet:
public class MoneyCalc { public void method(Object o) { System.out.println("Object Verion"); } public void method(String s) { System.out.println("String Version"); } public static void main(String args[]) { MoneyCalc question = new MoneyCalc(); question.method(null); } }
In this example, when the method method is invoked with the null literal, the Java compiler selects the method(String s) overload instead of the method(Object o) overload. This behavior is explained by the principle of most specific overload resolution.
According to the Java Language Specification (JLS), the compiler selects the "most specific" overload, which is "the one to which an invocation could be passed without a compile-time type error." Here, the null literal can be passed to the method(String s) overload without any error, but not to the method(Object o) overload.
Therefore, the Java compiler chooses the method(String s) overload, and the output of the program is "String Version".
However:
... public void method(StringBuffer sb) { System.out.println("StringBuffer Verion"); } ...
When a third overload is added to accept a StringBuffer parameter, the code will not compile. This is because now both the method(String s) and method(StringBuffer sb) overloads are equally specific, leading to an ambiguity and preventing the compiler from selecting the most appropriate overload.
The above is the detailed content of Why Does Passing Null to a Method Overload Choose the String Version Over the Object Version?. For more information, please follow other related articles on the PHP Chinese website!