How Does instanceof Work with Casting?

instanceof is a type test. It evaluates to true if the reference on the left is non-null and the object it points at is an instance of the type on the right, or of one of that type's subtypes. The reference itself is never dereferenced, so it is safe to use on a null reference — the result is simply false.

Three properties are worth stating precisely. First, it works on the runtime type, not the static type. If a variable is declared as Animal and holds a Dog, value instanceof Dog is true even though the compiler would not let you call a Dog method on the reference. Second, it returns false for null rather than throwing, which makes it the natural null check. Third, when the right-hand side is a type that the compiler can prove is impossible — for instance comparing against a final class that the object's type cannot be — the compiler may reject the comparison outright, turning a run-time failure into a build failure.

Its main use is guarding a downcast. The pattern if (value instanceof String) { String text = (String) value; ... } both narrows the type for the compiler and guarantees the cast will succeed, because the branch only runs when the test was true.

There is one subtlety about how the compiler handles the flow. Inside the if block the compiler knows the type has been narrowed, so the cast is redundant but harmless. Outside it, the compiler still sees the original type, which is why you cannot write the cast before the test. In modern Java the pattern matching form of instanceof removes that two-step dance entirely.

You test first and cast inside the branch. The compiler then treats the variable as the narrowed type inside the block, and the cast cannot fail at run time because it only executes when the test was true.

public class Main {
    public static void main(String[] args) {
        describe("hello");
        describe(42);
        describe(new int[] {1, 2});
        describe(3.5);
    }

    static void describe(Object value) {
        if (value instanceof String) {
            String text = (String) value;
            System.out.println("String of length " + text.length());
        } else if (value instanceof Integer) {
            int number = (Integer) value;
            System.out.println("Integer " + number + ", doubled = " + (number * 2));
        } else if (value instanceof int[]) {
            int[] numbers = (int[]) value;
            System.out.println("int[] of length " + numbers.length);
        } else {
            System.out.println("something else: " + value);
        }
    }
}

Notice that the third branch tests for int[], an array type. Arrays are objects in Java and have a runtime type of their own, so instanceof works with them — but a primitive array and an object array are different types, and value instanceof int[] is false for an Integer[].

Skip the check and the cast becomes a promise the compiler takes on trust. If the object turns out not to be the type you claimed, the JVM throws a ClassCastException at that exact line. In a deep call stack that exception surfaces far from the code that made the mistake, which is why the guarded form is worth the extra line.

Two more details. The order of the branches matters when one type is a subtype of another — you must test the more specific type first, or the broader branch will swallow the specific case. And because the test is on the runtime type, the compiler's flow analysis gives you the narrowed type inside the branch, which is what removes the need for a separate cast when you use the pattern matching form.

Pattern matching for instanceof is now a standard feature of the language. Before it, testing a type and then casting it took two steps and the compiler could not tell that the two were connected, so the cast had to be written out again even when it was obviously redundant.

The new form combines them. Instead of if (o instanceof String) { String s = (String) o; } you write if (o instanceof String s) { ... }, and the variable s is introduced, correctly typed, and in scope only inside the branch. The cast disappears, and so does the possibility of forgetting it.

Beyond the tidiness, the old pattern had a real defect that the new one removes: double evaluation. In if (o instanceof List && ((List<?>) o).size() > 0) the method call runs twice — once in the test and once in the body — and if the receiver is expensive or the state changes in between, the two calls can disagree. With the pattern form the value is bound once and both the test and the body use that single binding.

Scope is the other change worth noting. The pattern variable is in scope in the if block and nowhere else, so the compiler can prove it is definitely assigned wherever you can use it. That is what allows it to be a final local in practice, without you having to declare it final yourself.

The cost is a small amount of extra syntax for readers who know only the old form, and one restriction: the pattern variable shadows any local variable of the same name in the enclosing scope, which the compiler rejects unless the shadowing is legal.