what's the concept behind reference type casting?

[Ria von der Wartburg]

Hi everyone!

I'm studying for my OCA JP7 exam and today realized that I don't really understand the concept behind reference type casting.
Specifically, this example from one of the K&B self tests has me confused:

given that class Redwood extends Tree, we have this method:

void go2(Tree t1, Redwood r1){ /* some code */ } 

and then we invoke it like this:

go2( (Redwood) new Tree(), new Redwood());

The first parameter we're passing will NOT result in a compiler error. I'm wondering: why not? Why isn't (Redwood)new Tree() an obvious invalid cast? I'd like to know what it is that the compiler actually sees? What is it, that the cast operator is really acting upon? More generally: what exactly does the cast operator act upon, if there's no reference variable but only the 'instance creation expression'?
Had it been a reference variable to a Tree instance, then it would be clear to me because the compiler can't be sure that it's not really referring to a Redwood instance. So what is really happening here? I tried to find the answer in the JLS, but didn't find anything that would explain this.

I'd like to understand the concept behind this so I won't be in doubt about these kind of questions - hope you guys can help me!

- Ria

[Roel De Nijs]

Hi Ria,

First of all, a warm welcome to CodeRanch!

Ria von der Wartburg wrote:I'm studying for my OCA JP7 exam and today realized that I don't really understand the concept behind reference type casting.

Don't worry! Casting is one of the topics about which most questions are asked here on the ranch.

Ria von der Wartburg wrote:I'd like to understand the concept behind this so I won't be in doubt about these kind of questions - hope you guys can help me!

Let's see if I can help you a little bit. This topic will probably answer all your questions. Be sure to read also the topics mentioned in the posts.

If you still have questions after reading these threads, just let us know by replying to this thread.

Hope it helps!
Kind regards,
Roel

[Ria von der Wartburg]

Thanks a lot for your reply, Roel - and especially for the warm welcome!
You're actually one of my heroes because you scored 95%, haha.
Three and a half weeks from now I can post my results too...

Okay, I went through all the Threads you pointed out. That was indeed helpful because I just learned something new about the instanceof operator, namely that I can do this:

if(new Pizza() instanceof SalamiPizza);

(creating the Pizza instance right then and there)
And in the JLS paragraph you quoted in one of the threads it says
The RelationalExpression operand of the instanceof operator must be a reference type or the null type.
So that means "new Pizza()" counts as a reference type. I didn't know that. Maybe the compiler sees something like this:

if( <temporary reference of type Pizza to the Pizza-instance we just created> instanceof SalamiPizza)

That would make sense because the Pizza object itself is on the heap and we're inside a method, so of course the "new Pizza()"-expression must be some kind of reference. And the compiler only cares about the type of this reference.

Likewise, in the example above where we're doing an obvious invalid downcast:

go2( (Redwood)new Tree(), new Redwood());

the compiler only sees a Tree type reference that we're downcasting & passing to the method. Cooooooool... now it makes sense!

[Roel De Nijs]

Ria von der Wartburg wrote:You're actually one of my heroes because you scored 95%, haha.

I actually was hoping to be one of your heroes because my name is listed in K&B7

Ria von der Wartburg wrote:And in the JLS paragraph you quoted in one of the threads it says
The RelationalExpression operand of the instanceof operator must be a reference type or the null type.
So that means "new Pizza()" counts as a reference type. I didn't know that. Maybe the compiler sees something like this:

if( <temporary reference of type Pizza to the Pizza-instance we just created> instanceof SalamiPizza)

That would make sense because the Pizza object itself is on the heap and we're inside a method, so of course the "new Pizza()"-expression must be some kind of reference. And the compiler only cares about the type of this reference.

Don't know if the compiler sees a temporary reference. If you decompile that code, you still see the same statement:

if(new Pizza() instanceof SalamiPizza);

But more importantly conclusion from that JLS statement is that you can't use primitive variables with the instanceof operator. You'll get a compiler error if you try do otherwise.

int i1 = 5;
Integer i2 = 5;
System.out.println(i1 instanceof Number); // compiler error
System.out.println(i2 instanceof Number); // true 

Hope it helps!
Kind regards,
Roel

[Ria von der Wartburg]

Roel De Nijs wrote:
I actually was hoping to be one of your heroes because my name is listed in K&B7

Oh, now that you say it! I had skipped that part of the book, haha. Da's inderdaad nog veel beter!!

Roel De Nijs wrote:
Don't know if the compiler sees a temporary reference. If you decompile that code, you still see the same statement:

if(new Pizza() instanceof SalamiPizza);

Ah, that's interesting!
Hm, ok, so how do I find peace of mind in this case... hm, I'll just accept that 'new SomeClass()' is a "class instance creation expression" which somehow results in a reference to the object created by it. Actually I found a clue in JLS 12.5 (Creation of New Class Instances) where it says
"Just before a reference to the newly created object is returned as the result, the indicated constructor is processed to initialize the new object...".
Reference! Now the compiler is excused and I can sleep peacefully.

Roel De Nijs wrote:
But more importantly conclusion from that JLS statement is that you can't use primitive variables with the instanceof operator. You'll get a compiler error if you try do otherwise.

Yes, and that's very logical because there are no instances of primitive types.

[Roel De Nijs]

Ria von der Wartburg wrote:Now the compiler is excused and I can sleep peacefully.

Glad to hear you will have a good night's

(For those not so familiar with the Dutch language: Da's inderdaad nog veel beter! means That is indeed much better!)