Exam Lab Test 2 Question

[Mehdi Ben Larbi]

Hello everyone,

I am reviewing my answers to exam lab Test2 and there is an answer i can't understand,even with the explanation :

Here is the question :

     	 public class Lanka{
             public Lanka(Object o){
                  System.out.println("Object In");
             }
             public Lanka(Integer o){
                  System.out.println("Integer In");
             }
             public Lanka(Number o){
                  System.out.println("Number In");
             }
             public static void main(String args[]){
                  new Lanka(null);
             }
        }

The answer is : Integer In

I don't even know how to start thinking to solve this,i was sure it would raise a compiler error but it's working fine.
Any good explanation please ?

[Abimaran Kugathasan]

If the related methods arguments are in a hierarchy like your example, the method which has the most sub class reference will be invoked. And if the arguments are not in a hierarchy, then Compiler flag error. try with Integer and String.

[Mehdi Ben Larbi]

Abimaran Kugathasan wrote:If the related methods arguments are in a hierarchy like your example, the method which has the most sub class reference will be invoked. And if the arguments are not in a hierarchy, then Compiler flag error. try with Integer and String.

Thanks.
Where does this rule come from ? Is it specific to invocation with null ?

[Dieter Quickfend]

Just know that

1) a null value can be assigned to any reference of any class.
2) the compiler always tries to resolve a method call to the most specific parameter

Now, when you know this, try to solve this code fragment:

public class B{
    public void bB(Object b){}
    public void bB(Number b){}
    public void bB(Integer b){}
    public void bB(Byte b){}
    public static void main(String... args){
        B b = new B();
        b.bB(null);
}
}

What do you think will happen here?

[Shanky Sohar]

here it is
java.lang.Object
|
+--java.lang.Number
|
+--java.lang.Integer


so most subclassed version will be invoked will be called

[Prasad Kharkar]

well here hierarchy is
Object
Number
Byte and Integer


Now here
as methods with Byte and Integer are defined the call to the method is ambiguous
the compiler cannot decide whether to cal method with Integer or Byte

so compiler error will be shown

[Mehdi Ben Larbi]

Dieter Quickfend wrote:Just know that

1) a null value can be assigned to any reference of any class.
2) the compiler always tries to resolve a method call to the most specific parameter

Now, when you know this, try to solve this code fragment:

public class B{
    public void bB(Object b){}
    public void bB(Number b){}
    public void bB(Integer b){}
    public void bB(Byte b){}
    public static void main(String... args){
        B b = new B();
        b.bB(null);
}
}

What do you think will happen here?

I think it will provoke a compiler error because Byte and Integer are at the same level,no hierarchy between them so it's ambiguous.

Edit : I see you've already answered your question,i'am happy to see that i understood your explanation,thanks.
So this rule of class hierarchy only applies to a null reference ?
Because when i try to call the method with a String reference it works fine.

[Dieter Quickfend]

No, it applied to anything. If it's ambiguous, the compiler will protest. Null is just a really easy example of this behavior, because it can be assigned to anything and everything.

[Mehdi Ben Larbi]

Dieter Quickfend wrote:No, it applied to anything. If it's ambiguous, the compiler will protest. Null is just a really easy example of this behavior, because it can be assigned to anything and everything.

When i try to compile and run your example with an int it works fine and calls the Integer method,two questions here :

-Isn't it an ambiguous call ?
-Why did it choose to run the bB(Integer b) while we had bB(object b) ? Isn't boxing supposed to be chosen after casting ?

Really confused here.

[Abimaran Kugathasan]

Mehdi Ben Larbi wrote:
So this rule of class hierarchy only applies to a null reference ?

Why don't you try to come up with your own example? Check the below code!~

public class TestMethod	{
	public static void main(String[] args)	{
		Car c = new Car();
		new TestMethod().m(c);
	}

	void m(Vehicle c)	{
		System.out.println("Vehicle");
	}
	void m(Breakable b)	{
		System.out.println("Breakable");
	}
}

class Car extends Vehicle implements Breakable	{}
class Vehicle	{}
interface Breakable	{}

[Abimaran Kugathasan]

Mehdi Ben Larbi wrote:
-Isn't it an ambiguous call ?

Why do you think so? Which are the method, you consider, will be ambiguous?

Mehdi Ben Larbi wrote:
-Why did it choose to run the bB(Integer b) while we had bB(object b) ? Isn't boxing supposed to be chosen after casting ?

Which is the most sub class in the hierarchy? So, which would be invoked?

[Dieter Quickfend]

Mehdi Ben Larbi wrote:

Dieter Quickfend wrote:No, it applied to anything. If it's ambiguous, the compiler will protest. Null is just a really easy example of this behavior, because it can be assigned to anything and everything.

When i try to compile and run your example with an int it works fine and calls the Integer method,two questions here :

-Isn't it an ambiguous call ?
-Why did it choose to run the bB(Integer b) while we had bB(object b) ? Isn't boxing supposed to be chosen after casting ?

Really confused here.

What do you think, Mehdi? Is an int an instance of Object? can it widen to Object?

can an int be boxed to a Byte without casting?

[Mehdi Ben Larbi]

Abimaran Kugathasan wrote:
Why do you think so? Which are the method, you consider, will be ambiguous?

Thanks for the example,i understand the concept now.
Can't directly unbox form int to Byte so no ambiguous call here.
Check out this example :

public class Fizz{
	  
	void Test(long s){
		System.out.println("long");
	}
	void Test(float s){
		System.out.println("Float");
	}
     public static void main(String... args){
  

    	 int i=0;
    	 new Fizz().Test(i);
}
}

int can be cast to long or float,and there is no class hierarchy between long and float.
But there is no compiler error here,why ?
Primitive types maybe ?

[Mehdi Ben Larbi]

Dieter Quickfend wrote:
What do you think, Mehdi? Is an int an instance of Object? can it widen to Object?

can an int be boxed to a Byte without casting?

Yes it can.
When i write Object o=int reference it works perfectly.
I remember reading in the SCJP guide that the JVM would first choose widening then casting then var-args so why did it choose Integer over Object ?

[Dieter Quickfend]

an int cannot widen to Object.

It can however, autobox to Integer, and an Integer can widen to Object.

But if there is a method that takes an Integer, and int boxes to Integer... why would it widen to Object?

[Abimaran Kugathasan]

Mehdi Ben Larbi wrote:
int can be cast to long or float,and there is no class hierarchy between long and float.
But there is no compiler error here,why ?
Primitive types maybe ?

Primitive type are subjected to widening. There is no class for primitive types, then where is you class hierarchy come from?

[Abimaran Kugathasan]

Dieter Quickfend wrote:an int cannot widen to Object.

It can however, autobox to Integer, and an Integer can widen to Object.

But if there is a method that takes an Integer, and int boxes to Integer... why would it widen to Object?

If there is no method with the argument Integer, then the method with Object as argument will be invoked.

[Mehdi Ben Larbi]

Dieter Quickfend wrote:an int cannot widen to Object.

It can however, autobox to Integer, and an Integer can widen to Object.

But if there is a method that takes an Integer, and int boxes to Integer... why would it widen to Object?

I suppose it's the same for all primitive types ?
For example float autobox to Float then widen to Object ?

Abimaran Kugathasan wrote:
Primitive type are subjected to widening. There is no class for primitive types, then where is you class hierarchy come from?

Ok so this rule only applies to Objects ?

[Dieter Quickfend]

I'll recount you the most important rules for autoboxing, from Kathy & Bert's SCJP Study Guide (please forgive me and feel free to edit this out if I'm plagiarizing or something):

- Primitive widening uses the "smallest" method argument possible
- Used individually, boxing and var-args are compatible with overloading
- You CANNOT widen from one wrapper type to another (IS-A fails)
- You CANNOT widen and then box (an int can't become a Long)
- You can box and then widen (An int can become an Object, via Integer)
- You can combine var-args with either widening or boxing

I hope that settles it.

[Abimaran Kugathasan]

Mehdi Ben Larbi wrote:
I suppose it's the same for all primitive types ?
For example float autobox to Float then widen to Object ?

Yes, don't refere the book yet?

Mehdi Ben Larbi wrote:
Ok so this rule only applies to Objects ?

Which rule you are talking about?

[Mehdi Ben Larbi]

Dieter Quickfend wrote:I'll recount you the most important rules for autoboxing, from Kathy & Bert's SCJP Study Guide (please forgive me and feel free to edit this out if I'm plagiarizing or something):

- Primitive widening uses the "smallest" method argument possible
- Used individually, boxing and var-args are compatible with overloading
- You CANNOT widen from one wrapper type to another (IS-A fails)
- You CANNOT widen and then box (an int can't become a Long)
- You can box and then widen (An int can become an Object, via Integer)
- You can combine var-args with either widening or boxing

I hope that settles it.

Thanks a lot Dieter,it's clear now.

Abimaran Kugathasan wrote:
Which rule you are talking about?

Class hierarchy when invoking an overloaded method.
It's doesn't apply to primitives.


Anyway thanks again Dieter and Abimaran,you helped me a lot,everything is clear now.

[Abimaran Kugathasan]

You are Welcome!

[Dieter Quickfend]

[Shanky Sohar]

Dieter Quickfend wrote:Null is just a really easy example of this behavior, because it can be assigned to anything and everything.

No,It is wrong,
we cannot assign null to a primitive type
like we cannot do like this,

byte b1=null;
        int i=null;
        long=null;

[Abimaran Kugathasan]

Shanky Sohar wrote:
No,It is wrong,
we cannot assign null to a primitive type
like we cannot do like this,

byte b1=null;
        int i=null;
        long=null;

He mentioned about reference variable, not primitive variables!