Why can null be passed to an overloaded Java method? [duplicate] - java

This question already has answers here:
How to do method overloading for null argument?
(7 answers)
Closed 7 years ago.
I found this Java code from this site. I don't understand how it compiles without ambiguous error.
package swain.test;
public class Test {
public static void JavaTest(Object obj) {
System.out.println("Object");
}
public static void JavaTest(String arg) {
System.out.println("String");
}
public static void main(String[] args) {
JavaTest(null);
}
}
Output:
String

null can be passed to both JavaTest(String arg) and JavaTest(Object obj), so the compiler chooses the method with the more specific argument types. Since String is more specific than Object (String being a sub-class of Object), JavaTest(String arg) is chosen.
If instead of JavaTest(Object obj) you had JavaTest(Integer obj), the compilation would have failed, since Integer is not more specific than String and String is not more specific thanInteger`, so the compiler wouldn't be able to make a choice.

Related

tricky method Overloading in java [duplicate]

This question already has an answer here:
Method overloading/overriding in Java subclass object with superclass reference variable
(1 answer)
Closed 6 years ago.
class ABC {
void doMe(String s) {
System.out.println("String");
}
}
class XYZ extends ABC {
void doMe(Object o) {
System.out.println("Object");
}
}
public class StopStart {
public static void main(String[] args){
ABC o = new XYZ();
o.doMe(null);
}
}
What will happen and why?
string class extends Object. So which doMe() will execute.
Is it a compilation error?
Overloading is resolved in compile time, according to the compile time type of the variable o. Therefore doesn't matter which methods are defined in the XYZ sub-class. Only the methods of ABC are relevant.
Therefore only void doMe(String s) is considered by the compiler, and that's the chosen method.

Unexpected overloaded method compiler selection with null parameter [duplicate]

This question already has answers here:
How to do method overloading for null argument?
(7 answers)
Closed 6 years ago.
I am very surprised why output is very much different from what I am expecting , I have two overloaded methods, one having one String and the other an Object as parameter, while calling this method with null parameter, output is just printing
"String"
and not calling method having object as parameter.
Why does Java selects the method having String as parameter, how java determines which overloaded method to call ?
class TestingClass {
public void test(String s) {
System.out.println("String");
}
public void test(Object o) {
System.out.println("Object");
}
public static void main(String[] args) {
TestingClass q = new TestingClass();
q.test(null);
}
}
There is no overriding in this code, only method overloading. When the compiler has to choose which of the two test methods to execute (since null can be passed to both), it chooses the one with the more specific argument type - test(String s) - String is more specific than Object since it is a sub-class of Object.
The other method can be called using :
q.test((Object) null);
Without adding a possible new answer, let me suggest you to extend your code like following,
public class Overload {
public static void main(String[] args) {
new Overload().test(null);
}
public void test(String s) {
System.out.println("String");
}
public void test(Object o) {
System.out.println("Object");
}
public void test(Integer s) {
System.out.println("Integer");
}
}
Comment out any one of Object or Integer version any see it for yourself. The answer being already provided by others.

what is use of this::instanceMethod use as method parameter in java8 [duplicate]

This question already has answers here:
:: (double colon) operator in Java 8
(17 answers)
Closed 7 years ago.
I just started learning java8 stream api. I have seen a method which has input type Runnable interface even it's allow to pass this::greet as param. when program is run, why does this not call greet method? its output only Hello, world!2. why does it allow to pass such method even input is runnable interface?
public class TestAnno {
public static void main(String[] args) {
TestAnno anno=new TestAnno();
}
public TestAnno() {
display(this::greet); // what is use of calling this method
display(this.greet()); //compiler error: The method display(Runnable) in the type TestAnno is not applicable for the arguments (void)
}
private void display(Runnable s) {
System.out.println("Hello, world!2");
//Arrays.sort(new String[]{"1","2"}, String::compareToIgnoreCase);
}
public void greet() {
System.out.println("Hello, world! greet");
}
}
I have created interface to understand it.
public interface Inter1 {
void hello();
void hello1(int a);
}
Now I change display method param to Inter1 instead of Runnable. it throw error 'The target type of this expression must be a functional interface'.
like
public class TestAnno {
public static void main(String[] args) {
TestAnno anno=new TestAnno();
}
public TestAnno() {
display(this::greet); // The method display(Inter1) in the type TestAnno is not applicable for the arguments (this::greet)
display(()->this.greet());//The target type of this expression must be a functional interface
}
/*private void display(Runnable s) {
System.out.println("Hello, world!2");
Arrays.sort(new String[]{"1","2"}, String::compareToIgnoreCase);
}*/
private void display(Inter1 s){
}
public void greet() {
System.out.println("Hello, world! greet");
}
}
Can any one help on this!!
this::greet refers to a method with no parameters and no return value. As such, it matches the single method of the Runnable interface - void run().
Your display method accepts a Runnable instance. It must execute that's Runnable's run method in order for your greet method to be executed :
private void display(Runnable s) {
s.run();
System.out.println("Hello, world!2");
}
Your second attempt to call display can pass compilation if you turn it into a lambda expression :
display(()->this.greet());

Get Class Type from Reflection Java [duplicate]

This question already has answers here:
How do I find the caller of a method using stacktrace or reflection?
(13 answers)
Closed 7 years ago.
When I call on a method in a class, the method will get the java.lang.Class that called on it using sun.reflect.Reflection.getCallerClass(2). This is not what I want. I want the Reflection to return the class Object that called on it (i.e. if I call the method from the Bar class, the Reflection.getCallerClass() returns an object of type Bar)
Let's suppose I have this class:
public class Foo {
public static void printOutCallerObject() {
System.out.println(classTypeThatCalledOnMethod);
}
}
Called by:
public class Bar {
public static void main(String[] args) {
Foo.printOutCallerObject();
}
}
And then the program would print out "Bar".
Here's a quick demo of how you can get the calling class - you cannot get the calling object unless you pass it to the method because it is not on the stack.
public class ReflectDemo {
public static class Foo {
public static void printOutCallerObject() {
StackTraceElement[] trace = Thread.currentThread().getStackTrace();
// trace[0] is Thread.getStackTrace()
// trace[1] is Foo.printOutCallerObject()
// trace[2] is the caller of printOutCallerObject()
System.out.println(trace[2].getClassName());
}
}
public static class Bar {
public static void barMain() {
Foo.printOutCallerObject();
}
}
public static void main(String[] args) {
Foo.printOutCallerObject();
Bar.barMain();
}
}
This prints:
ReflectDemo
ReflectDemo$Bar
And Foo.printOutCallerObject(); will print out the class of whatever code calls it. The call to Thread.currentThread().getStackTrace() isn't cheap, so be aware that you may incur some runtime costs. This pattern is often used for logging, to record which piece of code triggered the logging call.

Couldn’t understand the output of this code? [duplicate]

This question already has answers here:
Strange Java null behavior in Method Overloading [duplicate]
(4 answers)
Closed 9 years ago.
public class Test {
public void method(String param)
{
System.out.println("String version");
}
public void method(StringBuffer param)
{
System.out.println("String Buffer");
}
public static void main(String args[])
{
Test test=new Test();
test.method(null);
}
}
This code result is compilation error says “reference to method is ambiguous”
public class Test
{
public void method1(Object param)
{
System.out.println("Object Version ");
}
public void method1(String param)
{
System.out.println("String Version ");
}
public static void main(String[] args)
{
Test test=new Test();
test.method1(null);
}
}
This code result is “String Version”
Actually I can’t understand the result of second piece of code. Why don’t both piece of code has the same result
In first case,
null is a subtype of every other reference type.
So, compiler finds ambiguity in deciding which method to call..
In second case, it finds more specific object for null which happens to be String. Hence it calls method1 and prints String Version

Categories