• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Constructor Overloading and null arguments

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anyone know why in the following code example the overloaded constructor taking a class B argument gets called when a null argument is called rather than either of the other 2 constructors?



Thanks Rob
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's a link to a recent thread that answers the same question.

javaranch
 
Robert Godfrey
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the link, Rovas. As the thread points out, you can cast null to a specific type in order to invoke a specific constructor which is reasonable. However when you just pass null, what's the rational for the compiler selecting the class B constructor (i.e. the most specific class) rather than the Object constructor?

Thanks Rob
 
Rovas Kram
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd like to know the rational too. Maybe it's just a convention. What's the rational for passing null to a constructor?
 
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For some more twist to the problem:

Add one more class:



And add this constructor to the class Test:



Now, the class will not compile and produces the following error:

-----------------------------
Test.java:16: reference to Test is ambiguous, both method Test(B) in Test and method Test(C) in Test match
{ new Test(null);
^
1 error
------------------------------

See, previously in absence of any ambiguity, the runtime method resolution mechanism, has chosen the constructor with argument of type B, as the class B is the lowest class in the hierarchy, and between Object, A and B, the mechanism does not face any conflict which to choose.

But, when constructor with parameter of type C(subclass of Object) is added, the mechanism cannot make out which to choose and now there are two choices - one with parameter B and one with parameter C.

HTH.
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's your answer, straight 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.


  • [ August 12, 2004: Message edited by: Corey McGlone ]
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic