4 Surprising Truths About Java Type Casting You Probably Don't Know

 

Most Java developers use type casting every day. It's a fundamental tool for working with class hierarchies and polymorphism. But what's really happening "under the hood"? When you cast an object, are you creating a new one? The answer might surprise you and change how you debug polymorphism and avoid subtle, surprising bugs.

This article reveals four counter-intuitive but critical truths about type casting, based on a deep dive into its internal mechanics.

1. Casting Creates a New Reference, Not a New Object

This is the most fundamental misconception about type casting. Let's set the record straight from the start. When you cast an object, you are not creating a new object in memory. You are not converting the existing object into something else. You are simply creating a new reference variable of a different type that points to the exact same existing object.

Consider this common example:

String s = new String("Durga");
Object o = (Object)s;

After this code runs, how many objects are in memory? Only one: the String object containing "Durga". What you have are two different reference variables, s (of type String) and o (of type Object), both pointing to that single object.

This is why the feature is called "type casting," not "object casting." You are changing the type of the reference, which acts like a label, not the object itself.

Strictly speaking, through type casting we are not creating any new object. For the existing object, we are providing another type of reference variable; that is, we are performing type casting but not object casting.

2. Parent References Can't Access Child-Specific Methods

Creating a new reference type for an object isn't just a cosmetic change; it has practical consequences for what you can do with that object. When you hold a child object using a parent reference, you limit your view of that object. Through the parent reference, you can only access the methods and variables defined in the parent class.

This is a cornerstone of polymorphism: you treat a Child object as a Parent to work with a generic interface, intentionally ignoring its specialized methods.

Let's look at the code. First, here are our class definitions:

class Parent {
    public void M1() {
        System.out.println("Parent Method");
    }
}

class Child extends Parent {
    public void M2() {
        System.out.println("Child-Specific Method");
    }
}

Now, let's see what happens when we use a Parent reference to hold a Child object:

Child c = new Child();
Parent p = c; // This is an implicit upcast, same as Parent p = (Parent)c;

p.M1(); // Valid - M1() is defined in the Parent class.
// p.M2(); // Compile-Time Error!

The call to p.M2() fails because the compiler only sees the Parent reference type, which has no knowledge of an M2() method. Even though the actual object in memory is a Child and does have that method, the reference type p prevents you from accessing it.

A parent reference can be used to hold a child object, but by using that reference, we can't call child-specific methods. We can call only methods available in the parent class.

3. Method Resolution Depends on Whether It’s static or Not

Here’s where the real magic—and confusion—lies. The way Java decides which method to run depends entirely on whether that method is an instance method or a static method. The distinction boils down to a core Java concept: runtime resolution (late binding) vs. compile-time resolution (early binding).

For Instance Methods (Overriding), It's All About the Object

Instance method overriding is the heart of polymorphism. In this case, method resolution is always based on the runtime object's actual type, regardless of the reference type you use to call it. This is late binding, where the JVM waits until runtime to look at the actual object in memory and check its virtual method table to decide which version of the method to execute.

Consider this class hierarchy where each class overrides M1():

class A {
    public void M1() { System.out.println("A"); }
}
class B extends A {
    public void M1() { System.out.println("B"); }
}
class C extends B {
    public void M1() { System.out.println("C"); }
}

Now, watch what happens when we cast the reference but the object stays the same:

C c = new C();

c.M1();                 // Output: C
((B)c).M1();            // Output: C
((A)(B)c).M1();         // Output: C

Even when we cast the reference to B and then to A, the output is always C. This is because the runtime object never changes—it's always a C object—and for overridden instance methods, the object's type is all that matters.

For static Methods (Hiding), It's All About the Reference

For static methods (a concept known as method hiding), the resolution is the complete opposite. It is always based on the reference type, not the underlying object. This is early binding. The compiler determines which method to call at compile-time based purely on the reference it sees, hard-wiring the call. This behavior is non-polymorphic and a frequent source of confusion for developers who expect it to behave like instance methods.

Here are the same classes, but with M1() declared as static:

class A {
    public static void M1() { System.out.println("A"); }
}
class B extends A {
    public static void M1() { System.out.println("B"); }
}
class C extends B {
    public static void M1() { System.out.println("C"); }
}

As a senior instructor, I must point out that calling a static method on an instance reference (c.M1()) is considered bad practice, precisely because it creates this confusion. You should always call them using the class name (C.M1()). But for this demonstration, let's see the result:

C c = new C();

c.M1();                 // Output: C (Reference is type C)
((B)c).M1();            // Output: B (Reference is type B)
((A)(B)c).M1();         // Output: A (Reference is type A)

Here, changing the reference type through casting directly changes which method is called. The output C, B, A proves that for static methods, the compiler resolves the call based on the reference, completely ignoring the runtime object's actual type.

4. Variable Resolution is Always Based on the Reference Type

The final truth follows the same logic as static methods: compile-time resolution. When it comes to accessing variables, the reference is king. The compiler decides which variable to access based only on the reference type, not the runtime object's type.

When a subclass declares a variable with the same name as one in a superclass, it's called variable shadowing. The specific variable being accessed is determined at compile-time based on the reference type, not the object's type.

Let's use our A, B, and C class hierarchy again, where each class defines an integer x:

class A {
    int x = 777;
}
class B extends A {
    int x = 888;
}
class C extends B {
    int x = 999;
}

Now, let's access x through different reference types pointing to the same C object:

C c = new C();

System.out.println(c.x);                 // Output: 999 (Reference is type C)
System.out.println(((B)c).x);            // Output: 888 (Reference is type B)
System.out.println(((A)(B)c).x);         // Output: 777 (Reference is type A)

Just like with static methods, the cast directly controls which x variable is accessed. The compiler binds the access to the variable declared in the reference's class.

Variable resolution is always based on reference type, but not based on the runtime object.

Conclusion

Type casting in Java is not about object conversion; it's about changing your perspective on an existing object by applying a different label—a new reference type. This new label comes with its own set of rules that are mostly resolved at compile-time. Understanding the difference between compile-time and runtime resolution is the key to mastering these behaviors.

The Golden Rule of Resolution

In Java, the runtime object's type only determines which overridden instance method is called. For everything else—static methods, all variables, and compile-time method availability checks—the reference type is all that matters.

Now that you see casting as a way to control access and perspective, how will this change the way you design and interact with your class hierarchies?