Method invocation with null

Consider:

Does it compile? What is the output?
Now consider:

Does it compile?
Strange. I would have expected that a null would be more explicitly an Object rather than any other class, causing the compiler to select the method that took an Object as a parameter. But it doesn't. Why not?

This doesn't compile. The problem is that, in the second example, two methods are "maximally specific" and the method call is considered ambiguous.
You can find more details about exactly how a method is chosen over another by looking at the JLS, §15.12.2.2 Choose the Most Specific Method. This is the part that explains why the method that takes an Integer or a String over one that takes an Object:

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.

If you still have questions about that, please ask. This topic can be rather confusing.
I hope that helps,
Corey

Thanks Corey. I think that the subtelty is that the compiler does not implicitly assign null a type in the first part of step 2 ( 15.12.2.1 Find Methods that are Applicable and Accessible).
For all other arguments (those that are not null), the type of the argument is explicitly known to the compiler in order to do the applicability test. So the type of null is kept flexible and indeterminate so to speak.
Thanks.

Hi Arun,
When ever you have situation like the example you gave where you have more than one method with the same name having some object as a parameter and if you are trying to access the methd with null then it will look for the lowest level object in the tree. For example if you have a situation like this
public class TestClass
{
public void method(Object o)
{
System.out.println("Object Version");
}
public void method(java.io.FileNotFoundException s)
{
System.out.println("java.io.FileNotFoundException Version");
}
public void method(java.io.IOException s)
{
System.out.println("IOException Version");
}
public static void main(String args[])
{
TestClass tc = new TestClass();
tc.method(null);
}
}
Here the lowest level class is java.io.FileNotFoundException as its a subclass of IOException and it is a sublcass of Object. So, in this case it will access the method with FileNotFoundException.
If you consider your first example it will access foo(Inetegr). But if you consider your second example it will not compile as you have more than one object with same hirearchy.
If you need any more explanation on this then please let me know.

Thanks Corey. I think that the subtelty is that the compiler does not implicitly assign null a type in the first part of step 2 ( 15.12.2.1 Find Methods that are Applicable and Accessible).

FYI: null has a type with no name, so it is not possible to use "null" or "Null" as a type. The programmer can, in practice, ignore the null type and use the null keyword that can be assigned to any reference variable. There is a widdening reference conversion from null to any array, class or interface type. (JLS 5.1.4)