Upcasting, downcasting, and instanceof

Written Explanation

Upcasting: always safe

Converting a child reference to a parent type is an upcast:

SavingsAccount s = new SavingsAccount("Ana", 1000.0, 0.02);
Account a = s;    // upcast: no cast operator needed

It is automatic and cannot fail, because every SavingsAccount really is an Account. The Java Language Specification calls this a widening reference conversion: it never needs an action at run time and never throws an exception, because the compiler can prove it is correct.

Note what an upcast does not do. It does not copy or change the object. a and s refer to the very same object (the check a == s is true). Only the view of it changes.

What a parent reference lets you do

The compiler checks every call against the reference type. Through an Account reference you may call only members that Account declares (or inherits):

Account a = new SavingsAccount("Ana", 1000.0, 0.02);
System.out.println(a.getRate());

Bad1.java:4: error: cannot find symbol
        System.out.println(a.getRate());
                            ^
  symbol:   method getRate()
  location: variable a of type Account
1 error

The object does have getRate(), but the compiler only sees the variable's declared type, and Account has no such method. This is a compile-time error, so you find out before the program runs. Overridden methods, such as monthEnd(), remain fully usable through the parent reference, and they still run the child's version.

Downcasting: explicit and risky

To get a child-typed view back, write the child type in parentheses. This is a downcast:

Account a = new SavingsAccount("Ana", 1000.0, 0.02);
SavingsAccount s = (SavingsAccount) a;   // downcast
System.out.println(s.getRate());          // now allowed

The compiler allows the cast because a SavingsAccount could be hiding behind an Account reference. It cannot know whether one actually is. So Java checks at run time. If the object's real class is the target type or a subclass of it, the cast succeeds. If not, the program throws a ClassCastException. (A null reference passes the cast and stays null.) The specification describes the same rule: narrowing reference conversions get a run-time check.

Account a = new CheckingAccount("Omar", 500.0);
SavingsAccount s = (SavingsAccount) a;   // compiles, then fails

Exception in thread "main" java.lang.ClassCastException: class CheckingAccount cannot be cast to class SavingsAccount (CheckingAccount and SavingsAccount are in unnamed module of loader 'app')
	at Ex2.main(Ex2.java:4)

Read it like a sentence: the real object is a CheckingAccount, and you asked to treat it as a SavingsAccount. The line number in the stack trace (a skill from the debugging module) points at the cast. The program stops there, so a wrong cast is a bug found late. If the two types are completely unrelated (neither is a subclass of the other), the compiler rejects the cast outright instead.

instanceof: check before you cast

The instanceof operator asks "is the object behind this reference of this type (or a subclass)?" and gives a boolean:

if (a instanceof SavingsAccount) {
    SavingsAccount s = (SavingsAccount) a;
    System.out.println(s.getRate());
}

Modern Java lets you combine the check, the cast, and the new variable into one step with a pattern variable:

if (a instanceof SavingsAccount s) {
    System.out.println(s.getRate());   // s is already a SavingsAccount here
}

The variable s exists only where the check is known to have succeeded. You can use it in the same condition after &&:

if (a instanceof SavingsAccount s && s.getRate() > 0.025) { ... }

This works because && stops at the first false, so s.getRate() is only evaluated when the check passed. (Using || instead would not compile, because s might not exist.)

Two more facts:

• instanceof is false for null, so a null check is not needed before it. Example 3 below confirms this by running.
• x instanceof Account is true for a SavingsAccount object: the check accepts the class and its subclasses.

If you are using an older Java version that does not support patterns, the two-line form above (check, then cast) does the same job.

The design smell

Downcasting is a legitimate tool, but a loop full of instanceof checks, each followed by a cast and a type-specific call, means the parent type is missing an operation. Last lesson showed the better fix: declare the operation on the parent (monthEnd()) and let each subclass override it. Rule of thumb: if the cast is only there to call the "same kind of thing" on each type, add a polymorphic method instead. Casting is justified when the information is truly specific to one subtype and does not make sense for the others.