{"title":"instanceof Operator","description":"","content":"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.\n\n---\n\n# What `instanceof` Returns\n\nThe `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.\n\n\n```java\npublic class InstanceofBasics {\n public static void main(String[] args) {\n Product item = new Book(\"Effective Java\", 39.99, \"Joshua Bloch\");\n\n System.out.println(\"item instanceof Book: \" + (item instanceof Book));\n System.out.println(\"item instanceof Product: \" + (item instanceof Product));\n System.out.println(\"item instanceof Object: \" + (item instanceof Object));\n System.out.println(\"item instanceof Electronics: \" + (item instanceof Electronics));\n }\n}\n\nclass Product {\n String name;\n double price;\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n String author;\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n}\n```\n\n\nThe `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.\n\nThe 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.\n\n\n```java\nBook book = new Book(\"Effective Java\", 39.99, \"Joshua Bloch\");\nboolean weird = book instanceof Electronics; // compile error: incompatible types\n```\n\n\nA `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.\n\nThe evaluation as a flowchart:\n\n\n```mermaid\nflowchart TD\n Start[\"obj instanceof Type\"]:::cyan\n NullCheck{\"obj is null?\"}:::orange\n TypeCheck{\"runtime class of obj
is Type or subtype of Type?\"}:::orange\n TrueResult[\"return true\"]:::green\n FalseResult[\"return false\"]:::red\n\n Start --> NullCheck\n NullCheck -->|yes| FalseResult\n NullCheck -->|no| TypeCheck\n TypeCheck -->|yes| TrueResult\n TypeCheck -->|no| FalseResult\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe 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.\n\n---\n\n# `null` Is Never an Instance\n\nA `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.\n\n\n```java\npublic class NullSafety {\n public static void main(String[] args) {\n Product missing = null;\n\n System.out.println(\"null instanceof Product: \" + (missing instanceof Product));\n System.out.println(\"null instanceof Book: \" + (missing instanceof Book));\n System.out.println(\"null instanceof Object: \" + (missing instanceof Object));\n }\n}\n\nclass Product {\n String name;\n}\n\nclass Book extends Product {}\n```\n\n\nEvery 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.\n\nThis 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.\n\n---\n\n# The Classic Pattern: Check Then Cast\n\nBefore 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.\n\n\n```java\npublic class CheckThenCast {\n public static void main(String[] args) {\n Product[] catalog = {\n new Book(\"Effective Java\", 39.99, \"Joshua Bloch\"),\n new Electronics(\"Wireless Mouse\", 24.99, 12),\n new GiftCard(\"BIRTHDAY-25\", 50.0)\n };\n\n for (Product item : catalog) {\n describe(item);\n }\n }\n\n public static void describe(Product item) {\n if (item instanceof Book) {\n Book book = (Book) item;\n System.out.println(\"Book by \" + book.author + \", $\" + book.price);\n } else if (item instanceof Electronics) {\n Electronics electronics = (Electronics) item;\n System.out.println(\"Electronics with \" + electronics.warrantyMonths\n + \"-month warranty, $\" + electronics.price);\n } else if (item instanceof GiftCard) {\n GiftCard card = (GiftCard) item;\n System.out.println(\"Gift card with $\" + card.balance + \" remaining\");\n }\n }\n}\n\nclass Product {\n String name;\n double price;\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n String author;\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n}\n\nclass GiftCard extends Product {\n double balance;\n GiftCard(String code, double balance) {\n super(code, balance);\n this.balance = balance;\n }\n}\n```\n\n\nThe 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.\n\nThis 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.\n\nJava 16 fixed this.\n\n---\n\n# Pattern Matching for `instanceof` (Java 16+)\n\nPattern 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`.\n\n\n```java\n// Requires Java 16 or later\npublic class PatternMatching {\n public static void main(String[] args) {\n Product[] catalog = {\n new Book(\"Effective Java\", 39.99, \"Joshua Bloch\"),\n new Electronics(\"Wireless Mouse\", 24.99, 12),\n new GiftCard(\"BIRTHDAY-25\", 50.0)\n };\n\n for (Product item : catalog) {\n describe(item);\n }\n }\n\n public static void describe(Product item) {\n if (item instanceof Book book) {\n System.out.println(\"Book by \" + book.author + \", $\" + book.price);\n } else if (item instanceof Electronics electronics) {\n System.out.println(\"Electronics with \" + electronics.warrantyMonths\n + \"-month warranty, $\" + electronics.price);\n } else if (item instanceof GiftCard card) {\n System.out.println(\"Gift card with $\" + card.balance + \" remaining\");\n }\n }\n}\n\nclass Product {\n String name;\n double price;\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n String author;\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n}\n\nclass GiftCard extends Product {\n double balance;\n GiftCard(String code, double balance) {\n super(code, balance);\n this.balance = balance;\n }\n}\n```\n\n\n`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.\n\nThe 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.\n\nPattern 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.\n\nPattern 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.\n\n---\n\n# Pattern Variable Scope and Flow Typing\n\nThe 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.\n\nInside the true branch of a plain `if`, the variable is in scope:\n\n\n```java\nif (item instanceof Book book) {\n System.out.println(book.author); // ok\n}\n// book is not in scope here\n```\n\n\nAfter a `&&` in the same condition, the variable is in scope:\n\n\n```java\nif (item instanceof Book book && book.author.startsWith(\"J\")) {\n System.out.println(book.author);\n}\n```\n\n\nThe second half of the `&&` is only evaluated when the first half is `true`, so `book` is guaranteed to be a real `Book` reference there.\n\nAfter `||`, the variable is **not** in scope, because the right side runs when the left side was `false`, meaning the check didn't succeed:\n\n\n```java\nif (item instanceof Book book || book.author.startsWith(\"J\")) { // compile error\n // ...\n}\n```\n\n\nThe 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.\n\n\n```java\n// Requires Java 16 or later\npublic class NegationPattern {\n public static void main(String[] args) {\n Product item = new Book(\"Effective Java\", 39.99, \"Joshua Bloch\");\n printAuthor(item);\n\n Product other = new Electronics(\"Mouse\", 24.99, 12);\n printAuthor(other);\n }\n\n public static void printAuthor(Product item) {\n if (!(item instanceof Book book)) {\n System.out.println(item.name + \" is not a book.\");\n return;\n }\n System.out.println(\"Author of \" + book.name + \": \" + book.author);\n }\n}\n\nclass Product {\n String name;\n double price;\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n String author;\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n}\n```\n\n\nAfter 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.\n\nThis 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.\n\n---\n\n# `instanceof` in `equals` Implementations\n\n`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.\n\nBefore pattern matching, the idiom looked like this:\n\n\n```java\n@Override\npublic boolean equals(Object other) {\n if (!(other instanceof Customer)) {\n return false;\n }\n Customer that = (Customer) other;\n return this.email.equals(that.email);\n}\n```\n\n\nTwo lines of boilerplate at the top, the same type name written twice, an explicit cast. Pattern matching collapses it.\n\n\n```java\n// Requires Java 16 or later\npublic class CustomerEquality {\n public static void main(String[] args) {\n Customer alice1 = new Customer(\"Alice\", \"alice@example.com\");\n Customer alice2 = new Customer(\"A. Smith\", \"alice@example.com\");\n Customer bob = new Customer(\"Bob\", \"bob@example.com\");\n\n System.out.println(\"alice1.equals(alice2): \" + alice1.equals(alice2));\n System.out.println(\"alice1.equals(bob): \" + alice1.equals(bob));\n System.out.println(\"alice1.equals(\\\"alice@example.com\\\"): \" + alice1.equals(\"alice@example.com\"));\n System.out.println(\"alice1.equals(null): \" + alice1.equals(null));\n }\n}\n\nclass Customer {\n String name;\n String email;\n\n Customer(String name, String email) {\n this.name = name;\n this.email = email;\n }\n\n @Override\n public boolean equals(Object other) {\n if (!(other instanceof Customer that)) {\n return false;\n }\n return this.email.equals(that.email);\n }\n\n @Override\n public int hashCode() {\n return email.hashCode();\n }\n}\n```\n\n\nThe `!(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.\n\nThis is the modern idiom for `equals`. Pattern matching writes the type guard at the top of the method in a single line.\n\n---\n\n# When to Use Polymorphism Instead\n\nA 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.\n\nConsider 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.\n\nWith `instanceof` chain dispatch:\n\n\n```java\n// Requires Java 16 or later\npublic class InstanceofDispatch {\n public static void main(String[] args) {\n Product[] catalog = {\n new Book(\"Effective Java\", 39.99, \"Joshua Bloch\"),\n new Electronics(\"Wireless Mouse\", 24.99, 12),\n new GiftCard(\"BIRTHDAY-25\", 50.0)\n };\n\n for (Product item : catalog) {\n System.out.println(describe(item));\n }\n }\n\n public static String describe(Product item) {\n if (item instanceof Book book) {\n return \"Book by \" + book.author + \", $\" + book.price;\n } else if (item instanceof Electronics electronics) {\n return \"Electronics with \" + electronics.warrantyMonths\n + \"-month warranty, $\" + electronics.price;\n } else if (item instanceof GiftCard card) {\n return \"Gift card with $\" + card.balance + \" remaining\";\n }\n throw new IllegalArgumentException(\"Unknown product type\");\n }\n}\n\nclass Product {\n String name;\n double price;\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n String author;\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n}\n\nclass GiftCard extends Product {\n double balance;\n GiftCard(String code, double balance) {\n super(code, balance);\n this.balance = balance;\n }\n}\n```\n\n\nAfter, with method overriding:\n\n\n```java\npublic class PolymorphicDispatch {\n public static void main(String[] args) {\n Product[] catalog = {\n new Book(\"Effective Java\", 39.99, \"Joshua Bloch\"),\n new Electronics(\"Wireless Mouse\", 24.99, 12),\n new GiftCard(\"BIRTHDAY-25\", 50.0)\n };\n\n for (Product item : catalog) {\n System.out.println(item.describe());\n }\n }\n}\n\nclass Product {\n String name;\n double price;\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \", $\" + price;\n }\n}\n\nclass Book extends Product {\n String author;\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n\n @Override\n public String describe() {\n return \"Book by \" + author + \", $\" + price;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n\n @Override\n public String describe() {\n return \"Electronics with \" + warrantyMonths + \"-month warranty, $\" + price;\n }\n}\n\nclass GiftCard extends Product {\n double balance;\n GiftCard(String code, double balance) {\n super(code, balance);\n this.balance = balance;\n }\n\n @Override\n public String describe() {\n return \"Gift card with $\" + balance + \" remaining\";\n }\n}\n```\n\n\nTwo 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.\n\nThe shape of the refactor as a diagram:\n\n\n```mermaid\nflowchart LR\n subgraph Before[\"Before: instanceof chain\"]\n Caller1[\"caller code\"]:::cyan\n Chain[\"if instanceof Book...
else if Electronics...
else if GiftCard...\"]:::orange\n Caller1 --> Chain\n end\n\n subgraph After[\"After: polymorphism\"]\n Caller2[\"caller code\"]:::cyan\n Call[\"item.describe()\"]:::green\n Sub[\"Book.describe()
Electronics.describe()
GiftCard.describe()\"]:::teal\n Caller2 --> Call\n Call --> Sub\n end\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe 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.\n\nWhen does `instanceof` chain dispatch still make sense?\n\n\n| Situation | Use `instanceof` chain | Use polymorphism |\n| --- | --- | --- |\n| Code owns all the subtypes and can add methods to them | No | Yes |\n| The types come from a library (no ownership) | Yes | Not possible |\n| The behavior is specific to one external caller and shouldn't pollute the type | Yes | No |\n| The set of cases is a sealed family and exhaustive switch is needed | Switch over the sealed type | Either works |\n| New cases are added frequently and every chain breaking is unacceptable | No | Yes |\n\n\nThe 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.\n\nA 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.\n\n---\n\n# A Peek at Pattern Matching for `switch` (Java 21+)\n\nJava 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.\n\nA short preview of the shape:\n\n\n```java\n// Requires Java 21 or later\npublic class SwitchPatternsPeek {\n public static void main(String[] args) {\n Product[] catalog = {\n new Book(\"Effective Java\", 39.99, \"Joshua Bloch\"),\n new Electronics(\"Wireless Mouse\", 24.99, 12),\n new GiftCard(\"BIRTHDAY-25\", 50.0)\n };\n\n for (Product item : catalog) {\n System.out.println(describe(item));\n }\n }\n\n public static String describe(Product item) {\n return switch (item) {\n case Book book -> \"Book by \" + book.author + \", $\" + book.price;\n case Electronics electronics -> \"Electronics with \" + electronics.warrantyMonths\n + \"-month warranty, $\" + electronics.price;\n case GiftCard card -> \"Gift card with $\" + card.balance + \" remaining\";\n default -> \"Other product: \" + item.name;\n };\n }\n}\n\nclass Product {\n String name;\n double price;\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n String author;\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\nclass Electronics extends Product {\n int warrantyMonths;\n Electronics(String name, double price, int warrantyMonths) {\n super(name, price);\n this.warrantyMonths = warrantyMonths;\n }\n}\n\nclass GiftCard extends Product {\n double balance;\n GiftCard(String code, double balance) {\n super(code, balance);\n this.balance = balance;\n }\n}\n```\n\n\nThe 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.\n\nEven 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.\n\n---\n\n# A Note on Generics\n\nOne last edge case. `instanceof` works with classes, abstract classes, and interfaces, but it does **not** work with generic type arguments like `List`. This compiles:\n\n\n```java\nObject value = new java.util.ArrayList();\nboolean isList = value instanceof java.util.List; // ok\n```\n\n\nThis does not:\n\n\n```java\nboolean isStringList = value instanceof java.util.List; // compile error\n```\n\n\nThe reason is **type erasure**: at runtime, the JVM only knows `value` is a `List`, not a `List`. 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.\n\nAn unbounded wildcard makes the erasure explicit:\n\n\n```java\nboolean isAnyList = value instanceof java.util.List; // ok\n```\n\n\nThat's accepted because `List` is the erased shape and matches the runtime fact.","pageType":"java"}

instanceof Operator

Get Premium