Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Method invocation with null

 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
R Arun
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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)
 
Not looking good. I think this might be the end. Wait! Is that a tiny ad?
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic