The instanceof operator checks whether a reference points to an object of a particular kind, inside an equals method, inside a defensive type check, anywhere that question needs an answer. This lesson covers the operator properly: how it works, the pattern-matching form added in Java 16 that removes the redundant cast, and why a long chain of instanceof checks is usually a signal that method overriding fits better.

The instanceof operator takes a reference on the left and a type on the right. It returns true when the reference points to an object of that type or any subtype, and false otherwise.

The item reference is declared as Product but the object it points to is actually a Book. instanceof Book is true because that's the object's runtime type. instanceof Product is true because Book extends Product. instanceof Object is true because every reference type in Java ends up at Object. instanceof Electronics is false because a Book and an Electronics are sibling types, neither is a subtype of the other.

The compiler also enforces a sanity rule at the type level. If the declared type on the left and the type on the right have no possible subtype relationship, the check is rejected outright.

A Book reference can never point to an Electronics object, so the compiler refuses to even ask. This catches a class of bugs before they reach runtime.

The evaluation as a flowchart:

The diagram shows the operator's two-step decision. First it filters out null. Then it asks whether the object's actual runtime class matches the requested type or any of its subtypes. The result is always a boolean, never an exception.

A null reference doesn't point to any object, so it isn't an instance of anything. The operator handles this case automatically. There is no NullPointerException to worry about.

Every check on null returns false, including instanceof Object. This is one of the rare places in Java where a null doesn't throw an exception. The practical consequence is that if (obj instanceof Product) works without first checking that obj is non-null. The check itself covers both cases.

This null-safety is the main reason instanceof is the right defensive check before casting. Casting a null to a specific type compiles and runs (the result is a null of that type), but the moment a method is called on it, a NullPointerException fires. An instanceof check first stops both the type mismatch case and the null case in one expression.

Before Java 16, the standard use of instanceof looked like this: ask if the object is the desired type, and if so, cast the reference to that type to call methods specific to it.

The shape is always the same: check, then cast, then use. The check asks "is this a Book?" and then, inside the branch where the answer is already known to be yes, the code casts to Book anyway. The compiler can't carry the information from the instanceof check into the body of the if block on its own, so the type name appears twice.

This redundancy isn't just stylistic. The cast can technically fail. An accidental cast of item to Electronics inside the Book branch would compile because the cast looks valid to the type system; the bug only surfaces at runtime when a ClassCastException fires. Repeating the type name in two places is exactly the kind of thing humans get wrong.

Java 16 fixed this.

Pattern matching for instanceof combines the test and the cast into a single expression. A pattern variable is named right after the type, and that variable is in scope wherever the check is known to be true.

item instanceof Book book does two things in one go. The first half tests whether item is a Book. The second half declares book as a new variable of type Book that holds the same reference. Inside the if body, book is used directly. No cast, no second mention of the type name.

The cast can't be wrong because the compiler generated it. Changing Book to Electronics in the declaration types the variable as Electronics and exposes only Electronics fields. The compiler keeps the test and the cast in sync.

Pattern matching for instanceof was a preview feature in Java 14 and 15 and became standard in Java 16. Any project on Java 16 or higher should prefer the pattern-matching form.

Pattern matching for instanceof compiles to the same bytecode as a manual check-and-cast. There's no runtime overhead. The benefit is at the source level: less code, no mismatched type names, no ClassCastException from a wrong cast inside the branch.

The pattern variable is only in scope where the compiler can prove the check succeeded. The rules sound complicated when written down, but they match the natural English reading of the code.

Inside the true branch of a plain if, the variable is in scope:

After a && in the same condition, the variable is in scope:

The second half of the && is only evaluated when the first half is true, so book is guaranteed to be a real Book reference there.

After ||, the variable is not in scope, because the right side runs when the left side was false, meaning the check didn't succeed:

The most useful case is the negation pattern. If the if test is !(item instanceof Book book) and the branch returns or throws, the compiler knows that any code after the if only runs when item is a Book. The pattern variable is in scope after the block.

After the return, any code that runs must have passed the check, so book is safe to use. This is called flow typing: the compiler tracks where a check is known to be true and makes the pattern variable usable in exactly those places.

This pattern is common in real code. Validate at the top of the method, return or throw early when the input doesn't fit, then use the bound pattern variable through the rest of the method body.

instanceof shows up most naturally inside equals. The contract for equals(Object other) requires accepting any Object reference and returning false for anything that isn't the right type. That's exactly what instanceof is built for.

Before pattern matching, the idiom looked like this:

Two lines of boilerplate at the top, the same type name written twice, an explicit cast. Pattern matching collapses it.

The !(other instanceof Customer that) form does three things at once. It rejects anything that isn't a Customer, it rejects null (because null instanceof X is false), and it binds that as a Customer for the rest of the method.

This is the modern idiom for equals. Pattern matching writes the type guard at the top of the method in a single line.

A long chain of instanceof checks dispatching on type is usually a smell. The reason: every time a new subtype is added, every chain needs a new branch. Forgetting one branch produces wrong behavior, because the new type falls through to whatever the last else does.

Consider the describe method from earlier. Each branch handles one subtype and calls fields specific to it. The natural Java fix is to move the per-type behavior into an overridable method on the parent class. Each subtype defines its own version, and the caller invokes the method without caring which subtype is on the other end.

With instanceof chain dispatch:

After, with method overriding:

Two things change. The caller now writes item.describe(), with no awareness of subtypes. And adding a new subtype, say Subscription, doesn't require touching the dispatch site at all. A new class that extends Product and overrides describe is enough; every loop that calls describe automatically picks up the new behavior.

The shape of the refactor as a diagram:

The diagram shows what moved. With the chain, the caller carried the responsibility of knowing every subtype. With polymorphism, the dispatch happens automatically through method override. The caller no longer enumerates the cases.

When does instanceof chain dispatch still make sense?

The main factor is type ownership. When the parent class and all its subtypes are part of the same codebase, adding a method, overriding it where needed, and letting the language route calls is the better path. If the types come from outside that control, no method can be added to them, and instanceof is the only option.

A rule of thumb: four or more instanceof branches dispatching on subtype is a sign that a method on the parent class would do the job better.

Java 21 finalized pattern matching for switch, which extends the same idea from if to switch. Instead of comparing values, a switch can match on types, and each case binds a pattern variable just like instanceof does.

A short preview of the shape:

The structure of this switch matches the instanceof chain almost exactly, but the syntax reads better and the compiler can check that every case is covered when the parent type is sealed. A sealed parent plus a pattern-matching switch is the modern Java idiom for closed case families.

Even with pattern-matching switch available, the polymorphism advice still holds. If the behavior naturally belongs to the type, a method on the type is cleaner than any switch. Switch is appropriate when the caller's logic is the right place for the case split, or when the types are not under the caller's control.

One last edge case. instanceof works with classes, abstract classes, and interfaces, but it does not work with generic type arguments like List<String>. This compiles:

This does not:

The reason is type erasure: at runtime, the JVM only knows value is a List, not a List<String>. The generic information is erased after compilation, so there's no way to check it. The rule: instanceof checks the raw class, not the parameterized type.

An unbounded wildcard makes the erasure explicit:

That's accepted because List<?> is the erased shape and matches the runtime fact.