Boxing null literal

[twoc andles]

Hi, i'm new here and i'm preparing for the scjp.

I've come across a question I don't find a reasonable answer.

Take a look at the following code:

public void m1( String s )
{}
public void m1( Integer i )
{}
pubic void test()
{
    // Ambiguous reference. An explicit cast does the trick, though.
    m1( null );
}

This code don't compile. It says null is an ambiguous reference, but if one of the m1 methods is removed, then the code is fine.

Now, if I change the m1 methods for these:

public void m1( String s )
{}
public void m1( Object i )
{}
pubic void test()
{
    // Code OK. It calls the String version. why?
    m1( null );
}

It seems the null literal works as a "wild" reference and that's what I don't understand.

[Nisha Ganeriwal]

String and Integer classes are on the same level unlike String and Object where Object is a superclass. Thus null is casted to String in the second case preferring the subclass.

[twoc andles]

So null is always casted to the "more specific class that can be matched". If there's more than 1 class not belonging to the same hierarchy then an "ambiguous reference" compiler error is notified. Is that so?

Thanks for the answer!

btw, not a "logical" behaviour, is it?

[Nisha Ganeriwal]

Any class is casted to the

more specific class that can be matched

. null is just a specific value that the class variable could have.

[twoc andles]

Nisha Ganeriwal wrote:Any class is casted to the

more specific class that can be matched

. null is just a specific value that the class variable could have.

but why the String takes preference over Object? or in general, why a specific class takes precedence over a class up in the hierarchy tree?

[Himanshu Mall]

@twoc andles

"NULL" has nothing to do with it.

We are talking about "Method Overload Resolution" here.

1) Most important thing to remember is that "Method Overload Resolution" happens at compile time i.e. Compiler does it.

2) Compiler resolves the method to be called in three phases mentioned below:

a) Accessibility: Whether the methods in question are accessible at the first place or not?
For example:

Suppose there is a class called PrintUtils

public class PrintUtils {
	
	public static void print(String s) {
		System.out.println("print(String) is being called");
	}
	
	private static void print(Integer i) {
		System.out.println("print(Integer) is being called");
	}

}


Another Class MethodOverloadDemo uses it.

/**
 * @author hmall
 *
 */
public class MethodOverloadDemo {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		PrintUtils.print(null);
	}

}

In the example above, print(Integer i) is not accessible to MethodOverloadDemo at the first place(Its a PRIVATE thing!), hence it is out of consideration. Result: print(String) is being called

B) After accessibility, compiler chooses the applicable methods.
A method is applicable if:
It number of argument matches.
Method can accept the arguments.

Example:

Change the private modifier to public.

/**
 * @author hmall
 *
 */
public class PrintUtils {
	
	public static void print(String s) {
		System.out.println("print(String) is being called");
	}
	
	public static void print(Integer i) {
		System.out.println("print(Integer) is being called");
	}

}

Now MethodOverloadDemo has access (as does everyone else) to both of the methods.

/**
 * @author hmall
 *
 */
public class MethodOverloadDemo {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		PrintUtils.print(null);
	}

}

Now both String and Integer references can refer to null (to nothing)
Integer i = null;
String s = null;

At this point Compiler has two methods, both accessible and applicable, so it performs the third step: It chooses the MOST SPECIFIC METHOD

What is MOST SPECIFIC METHOD: A method is less specific if it can take all arguments passed successfully to the other method.

Lets take the above mentioned example with this:

1) Can a reference of type Integer refer to String object? Answer is NO: One cannot say Integer i = "Himanshu";
2) Can a reference of type String refer to an Integer object? Answer is NO: One cannot say String s = 1;

Compiler has done with all three steps, still it cannot choose one method. So its an ambiguity.

Lets take other example:

 
/**
 * @author hmall
 *
 */
public class PrintUtils {
	
	public static void print(String s) {
		System.out.println("print(String) is being called");
	}
	
	public static void print(Object o) {
		System.out.println("print(Object) is being called");
	}

}

/**
 * @author hmall
 *
 */
public class MethodOverloadDemo {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		PrintUtils.print(null);
	}

}   

Now lets apply all three steps and see what happens:
1) Both are accessible
2) Both are applicable i.e. It is legal to say Object o = null; and String s = null;
3) Now third (choose most specific)
Can we say:
String s = new Object(); NO we cannot do that, pretty obviously
Can we say
Object o = new String("Himanshu"); YES, again obviously

In other words, print(Object o) can take all the arguments that can be passed to print(String s), however reverse is not true.

Now we, just like the compiler, can say print(Object o) is less specific and print(String s) is most/more specific and hence it wins.

Note: Apply the same rule irrespective of the whether actual argument is null or some other value.



Hope it helps.
Himanshu Mall

[twoc andles]

Thank you very much, Himanshu. Much clearer now.

[Unmesh Chowdhury]

Absolutely helpful.

[Lalit Mehra]

@Himanshu ... nice explanation.