Casting

[zzpprk]

Hi

I am just looking at some code where the something strange is happening.

I have the following.

Class A
Class B extends A
Class C extends A
Class D extends C

Class A has a method called m() which is overloaded in B and C.

The code I am looking at looks like the below where c is an instance of D.

((A)c).m()

I would expect the method m() on class A to be called.
What actually happens is that method m() on class C gets called.
Does that mean that the cast of c from D to A is redundant?

Does this type of casting occur at compile-time or at run-time?

Regards

Patrick

[Singing Boyo]

Casting an object does not change the object. Object c is still an object of class D, no matter how much casting you do. The method is overridden, not overloaded
for example...

class Printer{
     public void print(){
          System.out.println("A Printer");
     }
}
class PrinterSub extends Printer{
     @Override//Annotation for OVERRIDEN methods
     public void print(){
          System.out.println("A Printer Subclass")
     }
     
}
public static void main(String[] args){
     Printer p = new PrinterSub();
     p.print();
}

The output is this:

A Printer Subclass

This is because while the compiler regards p as a Printer, it is actually a PrinterSub.
Your cast

((A)c).m();

makes the compiler regard c as an Object of type A for that line, but it is still an object of type D.

As far as I know, there is no way to make it call A.m(). However, in C.m(), if you wrote this...

public void m(){
     super.m()
     //other code
}

C.m() would call A.m() as well as performing any additional code.

Hope this helps,
Singing Boyo

EDIT: Exceptions are thrown at runtime as far as I know, so casting is probably performed at runtime

[angryboy]

In this case, casting is an extra step done at runtime.

modding Boyo's code

public class Test {
  public static void main(String[] args){
       Printer p = new PrinterSub();
       ((Printer) p).print();
       ((PrinterSub) p).print();
       p.print();
  }
}

here's the bytecode:

   8:   aload_1
   9:   invokevirtual   #4; //Method Printer.print:()V

   12:  aload_1
  [B] 13:  checkcast       #2; //class PrinterSub[/B]
   16:  invokevirtual   #5; //Method PrinterSub.print:()V

   19:  aload_1
   20:  invokevirtual   #4; //Method Printer.print:()V

The jvm first looks for the method implementation in the method area, and takes the first one it finds. If its missing, it checks the superclass and so on. So casting is just an extra step here.

[Singing Boyo]

Another note...

It would not be good if casting worked as you had expected, especially in the case of abstract classes/interfaces. To change my code a bit...

interface Printer{
     void print();
}
class PrinterSub implements Printer{
     @Override
     public void print(){
          System.out.println("Print Method");
     }
}
public static void main(String[] args){
     PrinterSub p = new PrinterSub();
     ((Printer)p).print(); //if it worked like you thought it did, BANG, the program would crash
}

The above code works, because it calls, as AB said, the first implementation it finds. If it worked as you had thought, there wouldn't be an implementation, and then what? There is a reason for how this works.

Singing Boyo

[zzpprk]

Hi

I agree 100% with the following.

 
((A)c).m();

makes the compiler regard c as an Object of type A for that line, but it is still an object of type D.

My understanding is that the whole point of casting an object to its superclass is to call a method on that superclass. What would be the point of casting if that was not true?

Regards

Patrick

[RamyaSivakanth]

It is always advisable to use instanceOf and check before doing casting.

[Singing Boyo]

The thing is, casting an object to its superclass is only useful when reading objects from files when the 'real' class of the object has been changed, but the superclass has not been. This is to avoid incompatibilities between the old version and the new version, and part of why I base most of my classes on interfaces when I write large programs with regular changes.

[dlorde]

You can only call a superclass method of the same name by casting if the method is declared static, so it's tied to the class type rather than the instance, which means it isn't overridden and polymorphism doesn't apply.

If the method isn't static, polymorphism applies. This is why you can pass a subclass instance to a method taking a superclass type and still have it work correctly (polymorphically). Passing the subclass instance as a superclass argument is an implicit upcast.

[zzpprk]

You can only call a superclass method of the same name by casting if the method is declared static, so it's tied to the class type rather than the instance, which means it isn't overridden and polymorphism doesn't apply.

If the method isn't static, polymorphism applies. This is why you can pass a subclass instance to a method taking a superclass type and still have it work correctly (polymorphically). Passing the subclass instance as a superclass argument is an implicit upcast.

So what is the point of having something like that?

Class A
{
    public void m()
    {
    }
}

Claass B extends A
{
    public void m()
    {
    }
}

B c = new B();
((A)c).m();

If I undertand correctly, the cast of c from B to A is redundant. Right?

[Singing Boyo]

Right. Casting to superclasses is not really useful. However, as I said, if you write an object to a file, and then change that object, if you cast it to a superclass that has NOT changed, it should still be compatible. e.g

class ASubClass extends ASuperClass
void write(ASubClass ac){
     //write object to file
}
ASuperClass read(){
     //read and return object
}

The read method will work on any object written to a file, as long as ASuperClass is not changed. Any number of changes to ASubClass can occur. However, most changes to ASuperClass will make the files unreadable.

[AlmostAGuru]

Why dont you write an application and try..


Thread closed....


Jokers.....

[angryboy]

re: post#5

My understanding is that the whole point of casting an object to its superclass is to call a method on that superclass. What would be the point of casting if that was not true?

If you can do that, then it wouldn't be oop design. You might as well program in C then.

[dlorde]

It is always advisable to use instanceOf and check before doing casting.

Always? Not really...

[emceenugget]

There are two concepts to think about here, how Java actually works (irrefutable fact as it's just how it's coded for better or worse) and the concepts behind how Java works (arguable).

How casting works in Java is that it doesn't change an object. An object contains anything that is non-static in the class, including methods. So, if you cast and call a method on an object, it will use the method defined for whatever instance it is (unless like someone else said, that method is static, but you shouldn't be calling a static method from an object anyways).

The concept to think about here is what it conceptually means to subclass and override. D is a subclass of C, so it inherits properties of C. If C overrides a method of A, that means that it doesn't want to be treated like A in that aspect. Likewise, if D subclasses C, it also doesn't want to be treated like A in that way. If D does want to be treated like A and not C, then it should subclass A instead of C.

Unless you want to make the point that casting an instance of C to A should be treated like A when