help in method overloading

[frank]

public void show(Object o)
{
System.out.println("object");
}

public void show(String s)
{
System.out.println("String");
}


In main Method,


obj.show(null);


It will print "String".

Please give the Explanation for that

Thanks in Advance.

 

[Owen Jacobson]

public void show(Object o)
{
  System.out.println("object");

}

public void show(String s)
{
  System.out.println("String");

}

In main Method,

obj.show(null);

It will print  "String".

In the case of multiple overloads that match the arguments' static
types, the compiler will attempt to choose the "most specific"
overload - that is, the overload with the arguments furthest from
Object. In your example, String is more specific than Object, but if
you added a third overload

public void show (Integer i) {
System.out.println ("Integer");
}

the compiler would have two "most specific" overloads and would throw
an error.

-o

 

[frank]

In the case of multiple overloads that match the arguments' static
types, the compiler will attempt to choose the "most specific"
overload - that is, the overload with the arguments furthest from
Object. In your example, String is more specific than Object, but if
you added a third overload

  public void show (Integer i) {
    System.out.println ("Integer");
  }

the compiler would have two "most specific" overloads and would throw
an error.

-o

Thank You Very Much

 

[Tom Anderson]

In the case of multiple overloads that match the arguments' static
types, the compiler will attempt to choose the "most specific"
overload - that is, the overload with the arguments furthest from
Object. In your example, String is more specific than Object,

That's right, but in the case of literal null as an argument, it does seem
really counterintuitive. Personally, i'd prefer it if the compiler treated
this situation as an error, as in the case where you also have an Integer
(or whatever) version.

but if you added a third overload

public void show (Integer i) {
System.out.println ("Integer");
}

the compiler would have two "most specific" overloads and would throw
an error.

tom

 

[Daniel Pitts]

In the case of multiple overloads that match the arguments' static
types, the compiler will attempt to choose the "most specific"
overload - that is, the overload with the arguments furthest from
Object. In your example, String is more specific than Object, but if
you added a third overload

public void show (Integer i) {
System.out.println ("Integer");
}

the compiler would have two "most specific" overloads and would throw
an error.

-o

This is also somewhat esoteric. I've been programming in Java for years,
and I didn't know that . For *most* cases, its better not to use
overloading, but instead use similarly named methods that describe there
differences, for example:

public void showObject(Object o) { System.out.println("Object"); }
public void showString(String s) { System.out.println("String"); }

I would say the primary exception is when the input will be treated
exactly the same regardless of type (println for example), in which case
each overload should take an Object, or any type of primitive.

 

[Patel]

This is also somewhat esoteric. I've been programming in Java for years,
and I didn't know that .  For *most* cases, its better not to use
overloading, but instead use similarly named methods that describe there
differences, for example:

public void showObject(Object o) { System.out.println("Object"); }
public void showString(String s) { System.out.println("String"); }

I would say the primary exception is when the input will be treated
exactly the same regardless of type (println for example), in which case
each overload should take an Object, or any type of primitive.

Here "null" can be assigned to String, so when you have overloaded
methods , compiler searches for matching(specific) method first, in
this case first preference to the method which has String as an
argument. Object is generic(base class for all other classes) so when
there is no match "show(Object o)" will be called.

[Note]: Object class is the root class, so when there is no match ,
when all possibilities failed , method will be called which has
argument of type Object(final option).
Ex: Switch cases and the default. when all cases failed , default
block will be executed.

Thanks,
Patel.

 

[Daniel Pitts]

This is also somewhat esoteric. I've been programming in Java for years,
and I didn't know that . For *most* cases, its better not to use
overloading, but instead use similarly named methods that describe there
differences, for example:

public void showObject(Object o) { System.out.println("Object"); }
public void showString(String s) { System.out.println("String"); }

I would say the primary exception is when the input will be treated
exactly the same regardless of type (println for example), in which case
each overload should take an Object, or any type of primitive.

Here "null" can be assigned to String, so when you have overloaded
methods , compiler searches for matching(specific) method first, in
this case first preference to the method which has String as an
argument. Object is generic(base class for all other classes) so when
there is no match "show(Object o)" will be called.

[Note]: Object class is the root class, so when there is no match ,
when all possibilities failed , method will be called which has
argument of type Object(final option).
Ex: Switch cases and the default. when all cases failed , default
block will be executed.

Thanks,
Patel.

Were you actually replying to me, because I don't see how your response
makes sense to my message. Overloading resolution is at compile time,
so even if you have a "String" reference that is null, the reference
type is String, so the overload will be chosen based on that type. When
one needs to pass null to a particular overload that is ambiguous, it is
common to actually cast the null to the specific type, for example
show((Object)null);

The need to do this is the sign of either a poorly-design or a mis-used API.

 

[Lew]

....
Overloading resolution is at compile time,
so even if you have a "String" reference that is null, the reference
type is String, so the overload will be chosen based on that type.  When
one needs to pass null to a particular overload that is ambiguous, it is
common to actually cast the null to the specific type, for example
show((Object)null);

The need to do this is the sign of either a poorly-design or a mis-used API.

Daniel's points are consistent with Joshua Bloch's advice in /
Effective Java/ to "se overloading judiciously".