What is the difference between upcasting and downcasting in Java, and which one is implicit?

## Background: reference types and the type hierarchy In Java, an object lives on the heap and is reached through a **reference variable**. The variable has a *declared type* (also called its **static type** or *compile-time type*) — what the compiler thinks it is — and the object it points to has an *actual type* (its **runtime type** or *dynamic type*) — the real class it was created with via `new`. Classes form an inheritance tree. If `class Dog extends Animal`, then `Dog` is a **subtype** of `Animal`, and `Animal` is the **supertype**. The IS-A relationship reads downward-to-upward: a Dog IS-A Animal, but an Animal is not necessarily a Dog. ## Upcasting **Upcasting** is converting (assigning) a reference of a subtype to a variable of a supertype: ```java Dog d = new Dog(); Animal a = d; // upcast — implicit, no operator ``` It is **implicit**: you write no cast operator, because it is provably safe. Every Dog object genuinely *is* an Animal, so no runtime check is needed. Upcasting never throws. The cost is **narrowing of the visible interface**: through the `Animal` reference `a`, the compiler only lets you call members *declared on `Animal`*. A `Dog`-only method like `fetch()` is invisible, even though the object can still do it. (Overridden methods still dispatch to the Dog version at runtime — that is polymorphism — but the *compiler* checks against the declared type.) ## Downcasting **Downcasting** is the reverse: narrowing a supertype reference back to a subtype. It requires an **explicit cast operator**: ```java Animal a = new Dog(); Dog d = (Dog) a; // downcast — explicit d.fetch(); // now Dog-only members are visible ``` The compiler permits the cast only if the types are *related* (one could be the other). It cannot prove the object truly is a `Dog`, so it inserts a **runtime type check**. At execution the JVM compares the object's actual class against `Dog`: - if compatible, the cast succeeds; - if not (e.g. the object is really a `Cat`), it throws **`ClassCastException`**. ```java Animal a = new Cat(); Dog d = (Dog) a; // compiles fine, throws ClassCastException at runtime ``` Casting to a completely **unrelated** type (e.g. `(String) a` where neither is the other) is a *compile-time* error instead — the compiler knows it can never work. ## Why downcasting is risky and how to guard it Downcasting is the point where the compiler's safety net has a hole: it trusts your assertion about the runtime type. The standard guard is the **`instanceof`** operator, which tests the actual type *before* casting: ```java if (a instanceof Dog) { Dog d = (Dog) a; d.fetch(); } ``` Modern Java (16+) folds the test and cast into one **pattern-matching `instanceof`**: ```java if (a instanceof Dog d) { // tests AND binds d in one step d.fetch(); } ``` Note `null instanceof Dog` is always `false`, and casting `null` to any reference type is always allowed (a null reference has no runtime type to check), so `(Dog) null` never throws. ## Mental model - **Upcast** = generalize, implicit, always safe, hides specifics. - **Downcast** = specialize, explicit, may throw `ClassCastException`, reveals specifics. - Frequent downcasting is often a **design smell** — it suggests you've thrown away type information you should have kept, or that polymorphism (an overridden method) would express the intent better.