{"title":"Marker Interfaces","description":"","content":"A marker interface is an interface with no methods and no constants. It exists purely to tag a class with a capability, and the JVM or framework code reads that tag to change behavior. The pattern is older than annotations, still alive in the JDK, and worth understanding because the trade-offs between markers and annotations come up in interviews and in architectural decisions. This lesson covers what marker interfaces are, the four built-in ones in the JDK, how to write custom markers for an online store, and when annotations are the better choice.\n\n---\n\n# What a Marker Interface Actually Is\n\nMost interfaces describe behavior. A `Comparable` interface declares a `compareTo` method. A `Runnable` interface declares a `run` method. A marker interface declares nothing. Its body is empty.\n\n\n```java\npublic interface Refundable {\n}\n```\n\n\nThat's the entire declaration. No abstract methods, no default methods, no constants. A class that implements `Refundable` adds no methods. It gains a type that other code can detect.\n\nThe \"marker\" in the name is exactly what it sounds like. You're marking a class with a label that says \"this class supports X.\" The compiler can see the marker through the type system, and runtime code can detect it with `instanceof` or `Class.isAssignableFrom`. That's the entire mechanism.\n\n\n```java\npublic class MarkerBasics {\n interface Refundable {\n }\n\n static class DigitalBook {\n private final String title;\n public DigitalBook(String title) { this.title = title; }\n public String getTitle() { return title; }\n }\n\n static class PhysicalBook implements Refundable {\n private final String title;\n public PhysicalBook(String title) { this.title = title; }\n public String getTitle() { return title; }\n }\n\n public static void main(String[] args) {\n Object item1 = new DigitalBook(\"Effective Java\");\n Object item2 = new PhysicalBook(\"Clean Code\");\n\n System.out.println(\"Digital book is refundable? \" + (item1 instanceof Refundable));\n System.out.println(\"Physical book is refundable? \" + (item2 instanceof Refundable));\n }\n}\n```\n\n\nTwo classes, almost identical, but one of them implements `Refundable`. The runtime check `instanceof Refundable` separates them. The interface itself does nothing. The classes that implement it do nothing extra. The information lives entirely in the type system.\n\nThe question that follows is: why bother? Why not just add a `boolean isRefundable()` method, or a `refundable` field, or a `Set capabilities`?\n\nThe answer is that markers communicate metadata about a type through the type system itself. The compiler can enforce it. A method that accepts a parameter of type `Refundable` won't accept any object that hasn't been marked. The check is compile-time, not a string comparison or a flag lookup. That's the value, and it's the reason `Serializable` is the way it is rather than a boolean method on every class.\n\n---\n\n# Four JDK Markers\n\nThe JDK ships a handful of marker interfaces. Four of them are common, and each one demonstrates a different reason markers exist.\n\n\n| Interface | Purpose | What checks it |\n| --- | --- | --- |\n| `java.io.Serializable` | Class can be serialized to bytes | `ObjectOutputStream.writeObject` |\n| `java.lang.Cloneable` | Class supports `Object.clone()` | `Object.clone` (native code) |\n| `java.rmi.Remote` | Class methods can be invoked across JVMs | RMI runtime |\n| `java.util.RandomAccess` | List supports fast positional access | `Collections.binarySearch`, `Collections.shuffle` |\n\n\n### `Serializable`\n\n`Serializable` is the most familiar one. A class that wants to be writable by `ObjectOutputStream` has to implement it. The serialization machinery does an `instanceof Serializable` check on every object it encounters, and if the check fails, it throws `NotSerializableException`. The marker drives the decision.\n\n\n```java\nimport java.io.ByteArrayOutputStream;\nimport java.io.IOException;\nimport java.io.ObjectOutputStream;\nimport java.io.Serializable;\n\npublic class SerializableMarker {\n static class CartItem implements Serializable {\n private static final long serialVersionUID = 1L;\n private final String name;\n private final double price;\n\n public CartItem(String name, double price) {\n this.name = name;\n this.price = price;\n }\n }\n\n static class CartTotal {\n private final double total;\n public CartTotal(double total) { this.total = total; }\n }\n\n public static void main(String[] args) throws IOException {\n ByteArrayOutputStream bytes = new ByteArrayOutputStream();\n try (ObjectOutputStream out = new ObjectOutputStream(bytes)) {\n out.writeObject(new CartItem(\"Wireless Mouse\", 29.99));\n System.out.println(\"CartItem serialized, \" + bytes.size() + \" bytes.\");\n }\n\n try (ObjectOutputStream out = new ObjectOutputStream(new ByteArrayOutputStream())) {\n out.writeObject(new CartTotal(99.95));\n } catch (java.io.NotSerializableException e) {\n System.out.println(\"CartTotal failed: \" + e.getMessage());\n }\n }\n}\n```\n\n\nThe byte count varies by JDK version, but the shape is the same. `CartItem` carries the `Serializable` tag, so the stream accepts it. `CartTotal` doesn't, so the stream rejects it with `NotSerializableException`, and the exception message is the class name that failed the check. The check is purely an `instanceof Serializable` at the entry point.\n\n`Serializable` could have been a boolean method, and it wasn't. The library authors wanted the type system involved: any field of type `Serializable` (think `Serializable payload`) is guaranteed to be writable by `ObjectOutputStream`, and a field of type `Object` is not. That's a guarantee a method-based approach can't provide.\n\n### `Cloneable`\n\n`Cloneable` is an unusual marker in the JDK because the method it controls, `Object.clone`, isn't declared in the interface. Calling `clone` on an object that doesn't implement `Cloneable` throws `CloneNotSupportedException`. The check is inside the native `Object.clone` implementation.\n\n\n```java\npublic class CloneableMarker {\n static class Coupon implements Cloneable {\n private final String code;\n private final double discount;\n\n public Coupon(String code, double discount) {\n this.code = code;\n this.discount = discount;\n }\n\n @Override\n public Object clone() throws CloneNotSupportedException {\n return super.clone();\n }\n\n @Override\n public String toString() {\n return \"Coupon{\" + code + \", \" + discount + \"}\";\n }\n }\n\n static class WishlistEntry {\n private final String productName;\n\n public WishlistEntry(String productName) {\n this.productName = productName;\n }\n\n public Object tryClone() throws CloneNotSupportedException {\n return super.clone();\n }\n }\n\n public static void main(String[] args) throws CloneNotSupportedException {\n Coupon original = new Coupon(\"SAVE10\", 0.10);\n Coupon copy = (Coupon) original.clone();\n System.out.println(\"Cloned coupon: \" + copy);\n\n WishlistEntry entry = new WishlistEntry(\"Headphones\");\n try {\n entry.tryClone();\n } catch (CloneNotSupportedException e) {\n System.out.println(\"WishlistEntry failed: not Cloneable\");\n }\n }\n}\n```\n\n\nThe `Object.clone` source code is roughly \"if `this` isn't a `Cloneable`, throw `CloneNotSupportedException`; otherwise return a shallow copy.\" The marker is the gate. `Cloneable` has its own deeper issues (it's often considered a design mistake), but the pattern itself is a classic marker interface.\n\n### `RandomAccess`\n\n`RandomAccess` is an interesting marker because it carries no instruction. It carries a performance hint.\n\nA `List` marked with `RandomAccess` promises that `list.get(i)` is fast (constant time). `ArrayList` implements it. `LinkedList` doesn't. Library algorithms check the marker and pick a different strategy depending on what they see.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.LinkedList;\nimport java.util.List;\nimport java.util.RandomAccess;\n\npublic class RandomAccessHint {\n public static void main(String[] args) {\n List arrayList = new ArrayList<>();\n List linkedList = new LinkedList<>();\n\n System.out.println(\"ArrayList is RandomAccess? \" + (arrayList instanceof RandomAccess));\n System.out.println(\"LinkedList is RandomAccess? \" + (linkedList instanceof RandomAccess));\n }\n}\n```\n\n\nThe JDK's `Collections.binarySearch` does this check. If the list is `RandomAccess`, it uses indexed access. Otherwise it falls back to an iterator-based binary search, because calling `get(i)` repeatedly on a `LinkedList` is O(n) per call, which would turn an O(log n) search into O(n log n) accidental quadratic.\n\n`binarySearch` on a `LinkedList` of 10,000 elements without the `RandomAccess` fallback would do roughly 14 lookups, each costing up to 10,000 traversal steps. The fallback to iterator-based search makes it linear time overall, which is much better than the naive version.\n\n### `Remote`\n\n`Remote` from RMI (Remote Method Invocation) marks an interface whose methods can be called across a JVM boundary. It's the oldest of the four, and the pattern is identical. RMI's runtime checks `instanceof Remote` when deciding whether to generate a stub for an object.\n\n---\n\n# Why the Type System, Not a Boolean Method\n\nWhy not just write a `boolean isRefundable()` method on every product? Why introduce an empty interface?\n\nThere are three reasons, and the first is the strongest.\n\n### Reason 1: Compile-Time Checking\n\nA method that takes a `Refundable` parameter can only be called with refundable objects. The compiler enforces it. There's no way to \"forget\" to mark something and then pass it to a refund handler.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class CompileTimeChecking {\n interface Refundable {\n }\n\n static class DigitalDownload {\n private final String name;\n public DigitalDownload(String name) { this.name = name; }\n }\n\n static class Book implements Refundable {\n private final String title;\n public Book(String title) { this.title = title; }\n @Override public String toString() { return \"Book: \" + title; }\n }\n\n static class Shoes implements Refundable {\n private final String model;\n public Shoes(String model) { this.model = model; }\n @Override public String toString() { return \"Shoes: \" + model; }\n }\n\n // The parameter type forces every caller to prove the item is refundable.\n static void processRefund(Refundable item) {\n System.out.println(\"Refund issued for \" + item);\n }\n\n public static void main(String[] args) {\n List refundables = new ArrayList<>();\n refundables.add(new Book(\"Effective Java\"));\n refundables.add(new Shoes(\"Running Shoes Size 9\"));\n\n for (Refundable item : refundables) {\n processRefund(item);\n }\n\n // processRefund(new DigitalDownload(\"Album\")); // would not compile\n }\n}\n```\n\n\nIf you uncomment the line, the file doesn't compile, because `DigitalDownload` isn't a `Refundable`. The compiler catches the bug at build time. A `boolean isRefundable()` method couldn't do that, because every call site would have to remember to check the flag, and one missing check is one bug.\n\nA method-style `Set capabilities` is even worse. The capability is a string, so a typo (`\"refundabel\"`) compiles fine and fails silently at runtime.\n\n### Reason 2: Inheritance Works Automatically\n\nMarkers participate in inheritance the same way any interface does. A subclass automatically inherits its parent's marker interfaces. A class can mark itself with several interfaces. A marker can extend another marker.\n\n\n```mermaid\nclassDiagram\n class Refundable {\n <>\n }\n class GiftWrappable {\n <>\n }\n class Book {\n }\n class Hardcover {\n }\n Refundable <|.. Book\n GiftWrappable <|.. Book\n Book <|-- Hardcover\n\n style Refundable fill:#00ceff,stroke:#000,color:#000\n style GiftWrappable fill:#ffa94d,stroke:#000,color:#000\n style Book fill:#69db7c,stroke:#000,color:#000\n style Hardcover fill:#38d9a9,stroke:#000,color:#000\n```\n\n\n`Book` is both `Refundable` and `GiftWrappable`. `Hardcover` extends `Book`, so a `Hardcover` instance is both `Refundable` and `GiftWrappable` without writing a single extra line. With a method-based approach, you'd have to remember to override or re-declare each capability in every subclass.\n\n\n```java\npublic class InheritedMarkers {\n interface Refundable {}\n interface GiftWrappable {}\n\n static class Book implements Refundable, GiftWrappable {\n private final String title;\n public Book(String title) { this.title = title; }\n public String getTitle() { return title; }\n }\n\n static class Hardcover extends Book {\n public Hardcover(String title) { super(title); }\n }\n\n public static void main(String[] args) {\n Hardcover item = new Hardcover(\"Effective Java\");\n System.out.println(\"Is Refundable? \" + (item instanceof Refundable));\n System.out.println(\"Is GiftWrappable? \" + (item instanceof GiftWrappable));\n }\n}\n```\n\n\nThe `Hardcover` class never mentions `Refundable` or `GiftWrappable`, but both checks return `true` because the markers travel down the hierarchy.\n\n### Reason 3: Cheap Runtime Checks\n\nAn `instanceof` check is one of the cheapest operations the JVM can do. On most JVMs it compiles down to a couple of pointer reads. The HotSpot JIT optimizes it aggressively, and the cost is comparable to a null check.\n\nThis is the foundation for why JDK code uses markers in hot paths. `Collections.binarySearch` performs an `instanceof RandomAccess` check exactly once per call, and the JIT can hoist or specialize it. The cost is invisible.\n\nA single `instanceof` check is typically 1-3 nanoseconds on modern hardware. Reflection-based annotation reads, by contrast, can be 100-1000 times slower per call because they go through `Class.getAnnotation`, which builds maps and proxies. Cache annotation lookups if the cost matters.\n\n---\n\n# Building a Custom Marker: `Refundable` in a Cart\n\nConsider an online store with several kinds of products. Some are refundable, some aren't. The cart's refund handler should only touch refundable items.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class RefundableCart {\n interface Refundable {\n }\n\n static abstract class Product {\n protected final String name;\n protected final double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public double getPrice() { return price; }\n\n @Override\n public String toString() {\n return name + \" ($\" + price + \")\";\n }\n }\n\n static class Book extends Product implements Refundable {\n public Book(String name, double price) { super(name, price); }\n }\n\n static class Headphones extends Product implements Refundable {\n public Headphones(String name, double price) { super(name, price); }\n }\n\n // Digital downloads in this store are non-refundable.\n static class DigitalDownload extends Product {\n public DigitalDownload(String name, double price) { super(name, price); }\n }\n\n // Final-sale clearance items skip the marker too.\n static class ClearanceItem extends Product {\n public ClearanceItem(String name, double price) { super(name, price); }\n }\n\n static class Cart {\n private final List items = new ArrayList<>();\n\n public void add(Product item) {\n items.add(item);\n }\n\n public double processRefunds() {\n double refunded = 0.0;\n for (Product item : items) {\n if (item instanceof Refundable) {\n System.out.println(\"Refunded: \" + item);\n refunded += item.getPrice();\n } else {\n System.out.println(\"Cannot refund: \" + item);\n }\n }\n return refunded;\n }\n }\n\n public static void main(String[] args) {\n Cart cart = new Cart();\n cart.add(new Book(\"Effective Java\", 39.99));\n cart.add(new DigitalDownload(\"Album: Greatest Hits\", 9.99));\n cart.add(new Headphones(\"Studio Headphones\", 89.99));\n cart.add(new ClearanceItem(\"Last-Season Shirt\", 14.99));\n\n double total = cart.processRefunds();\n System.out.printf(\"Total refunded: $%.2f%n\", total);\n }\n}\n```\n\n\nThe cart's `processRefunds` does not depend on specific subclasses. It checks one capability with `instanceof`, branches, and moves on. Adding a new refundable product type (say, `Toys`) is one line: `class Toys extends Product implements Refundable`. The cart code never changes.\n\nCompare that to a flag-based design. With a boolean field, every new product class has to remember to set the flag correctly. With a method, every class has to override it. The marker version is harder to forget, because the type system flags the omission whenever a refund handler is involved.\n\n---\n\n# Multiple Markers on One Class\n\nMarkers compose. A single class can implement several markers without any conflict, because none of them declares anything that could collide. Orthogonal capabilities can be added independently.\n\nAn online store has four orthogonal capabilities a product might have. Some products are refundable. Some can be gift-wrapped. Some qualify for bulk-order pricing. Some can be cancelled after purchase. A given product might support any combination.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class MultipleMarkers {\n interface Refundable {}\n interface GiftWrappable {}\n interface BulkOrderable {}\n interface Cancellable {}\n\n static abstract class Product {\n protected final String name;\n public Product(String name) { this.name = name; }\n @Override public String toString() { return name; }\n }\n\n static class Book extends Product\n implements Refundable, GiftWrappable, BulkOrderable, Cancellable {\n public Book(String name) { super(name); }\n }\n\n static class Subscription extends Product implements Cancellable {\n public Subscription(String name) { super(name); }\n }\n\n static class GiftCard extends Product implements GiftWrappable, BulkOrderable {\n public GiftCard(String name) { super(name); }\n }\n\n static class DigitalDownload extends Product {\n public DigitalDownload(String name) { super(name); }\n }\n\n static void describe(Product item) {\n List capabilities = new ArrayList<>();\n if (item instanceof Refundable) capabilities.add(\"refundable\");\n if (item instanceof GiftWrappable) capabilities.add(\"gift-wrappable\");\n if (item instanceof BulkOrderable) capabilities.add(\"bulk-orderable\");\n if (item instanceof Cancellable) capabilities.add(\"cancellable\");\n System.out.println(item + \": \" + capabilities);\n }\n\n public static void main(String[] args) {\n describe(new Book(\"Effective Java\"));\n describe(new Subscription(\"Monthly Magazine\"));\n describe(new GiftCard(\"$50 Store Credit\"));\n describe(new DigitalDownload(\"Album Download\"));\n }\n}\n```\n\n\nEach capability is a separate marker. Each class picks its own combination. The `describe` method asks four independent questions and gets four independent answers. There's no flag to forget, no string to typo, no enum to extend.\n\nThe last property matters. If `capabilities` were an enum, adding a new capability would require touching the enum file and every switch statement that uses it. With markers, adding `Returnable` is one line: declare the interface. Existing code doesn't compile against the new marker (it doesn't need to), and any class that wants to opt in adds it to its `implements` clause.\n\n---\n\n# How JDK Methods Actually Use Markers\n\n`Serializable` and `RandomAccess` aren't the only markers used inside the JDK, but they're the two whose internal use is easy to verify. The pattern is the same in both cases: a piece of library code does an `instanceof` check at a single entry point and changes its behavior.\n\nA sketch of what `ObjectOutputStream.writeObject` does, in pseudocode based on the real source:\n\n\n```shell\nwriteObject(obj):\n if obj is null -> write null tag\n if obj is String -> write string\n if obj is array -> write array\n if obj is Enum -> write enum\n if obj instanceof Serializable -> serialize fields\n else throw NotSerializableException\n```\n\n\nThe marker is the gate. Everything else in the serialization machinery (reading fields with reflection, handling cycles, writing the stream header) is downstream of that one check.\n\n`Collections.binarySearch` is even cleaner:\n\n\n```shell\nbinarySearch(list, key):\n if list instanceof RandomAccess or list.size() < THRESHOLD:\n indexedBinarySearch(list, key) // uses list.get(i)\n else:\n iteratorBinarySearch(list, key) // uses ListIterator.next()\n```\n\n\nHere the marker informs an algorithm choice, not a yes/no decision. Both paths return the same result. One is faster for the underlying list type. This is the second flavor of marker: not a permission gate, but a hint.\n\n\n```mermaid\nflowchart LR\n Call[binarySearch
list, key]:::cyan --> Check{list instanceof
RandomAccess?}:::orange\n Check -->|yes| Indexed[Indexed search
list.get i]:::green\n Check -->|no| Iter[Iterator search
walk once]:::teal\n Indexed --> Result[Return index]:::cyan\n Iter --> Result\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 captures the entire decision. One `instanceof` check, two paths, one return point. Both paths produce the same answer, but one is much faster for the underlying list type.\n\n---\n\n# Marker Interfaces vs Annotations\n\nJava 5 introduced annotations, and since then, the question \"should I use a marker interface or an annotation?\" has become one of the standard design choices. Both can tag a class. Both can be checked at runtime. They aren't interchangeable, and the trade-offs are real.\n\nAn annotation version of `Refundable` looks like this:\n\n\n```java\nimport java.lang.annotation.ElementType;\nimport java.lang.annotation.Retention;\nimport java.lang.annotation.RetentionPolicy;\nimport java.lang.annotation.Target;\n\npublic class AnnotationMarker {\n @Retention(RetentionPolicy.RUNTIME)\n @Target(ElementType.TYPE)\n @interface Refundable {\n }\n\n static abstract class Product {\n protected final String name;\n protected final double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n @Override public String toString() { return name + \" ($\" + price + \")\"; }\n }\n\n @Refundable\n static class Book extends Product {\n public Book(String name, double price) { super(name, price); }\n }\n\n static class DigitalDownload extends Product {\n public DigitalDownload(String name, double price) { super(name, price); }\n }\n\n static void processRefund(Product item) {\n if (item.getClass().isAnnotationPresent(Refundable.class)) {\n System.out.println(\"Refunded: \" + item);\n } else {\n System.out.println(\"Cannot refund: \" + item);\n }\n }\n\n public static void main(String[] args) {\n processRefund(new Book(\"Effective Java\", 39.99));\n processRefund(new DigitalDownload(\"Album\", 9.99));\n }\n}\n```\n\n\nFunctionally, this works. The check is `isAnnotationPresent` instead of `instanceof`, but the outcome is the same. The differences show up across five dimensions.\n\n\n| Dimension | Marker Interface | Runtime Annotation |\n| --- | --- | --- |\n| Compile-time check | Yes (parameter type can be the marker) | No (can't write `void process(@Refundable Object o)` and have the compiler enforce it) |\n| Runtime check cost | `instanceof`: 1-3 ns | `isAnnotationPresent`: 50-500 ns, builds maps |\n| Inheritance | Inherited automatically by subclasses | Only with `@Inherited`, and only for class-level annotations on direct parents |\n| Carries metadata | No (interface is empty) | Yes (annotation can have fields: `@Refundable(windowDays = 30)`) |\n| Pollutes type hierarchy | Yes (every marker is another supertype) | No (annotation is a sidecar) |\n\n\nThe compile-time check is the marker's biggest advantage. If `processRefund` takes a `Refundable` parameter, only refundable items can be passed. The annotation version's parameter has to be `Object` or `Product`, and the check happens at runtime. If the check is omitted, the code still compiles.\n\nThe runtime cost difference matters in hot paths. `instanceof` is a JVM-level operation that the JIT can fold into nothing in some cases. `isAnnotationPresent` walks the class's annotation map, which involves hash lookups and (on first access) builds proxy objects. For a refund handler called once per order, neither cost matters. For a hot inner loop that classifies a million events per second, the difference is significant.\n\n`Class.getAnnotation` and `isAnnotationPresent` build and cache an annotation map per class. The first call per class is slow (proxy creation, internal map setup). Subsequent calls are cheaper but still involve a `HashMap` lookup. Hot-path code should cache the result of the first check rather than calling `isAnnotationPresent` repeatedly.\n\nInheritance is where annotations get awkward. By default, an annotation on a parent class does not appear on a subclass. The annotation declaration needs `@Inherited`, and even then, only direct class-level annotations are inherited, not annotations on interfaces. A marker interface, being just an interface, follows the normal interface inheritance rules without any extra effort.\n\n\n```java\nimport java.lang.annotation.ElementType;\nimport java.lang.annotation.Inherited;\nimport java.lang.annotation.Retention;\nimport java.lang.annotation.RetentionPolicy;\nimport java.lang.annotation.Target;\n\npublic class AnnotationInheritance {\n @Retention(RetentionPolicy.RUNTIME)\n @Target(ElementType.TYPE)\n @interface NonInherited {}\n\n @Retention(RetentionPolicy.RUNTIME)\n @Target(ElementType.TYPE)\n @Inherited\n @interface Inheritable {}\n\n @NonInherited\n @Inheritable\n static class Parent {}\n\n static class Child extends Parent {}\n\n public static void main(String[] args) {\n System.out.println(\"Child has @NonInherited? \"\n + Child.class.isAnnotationPresent(NonInherited.class));\n System.out.println(\"Child has @Inheritable? \"\n + Child.class.isAnnotationPresent(Inheritable.class));\n }\n}\n```\n\n\n`@NonInherited` is the default behavior: subclasses don't see the parent's annotation. `@Inheritable` flips that, but the option is opt-in and only covers class-level annotations. Marker interfaces bypass this entire complication.\n\nThe annotation's main feature is metadata. A marker is yes-or-no. An annotation can carry data:\n\n\n```java\n@Refundable(windowDays = 30, restockingFee = 0.10)\nclass Book extends Product { ... }\n```\n\n\nA marker can't express \"refundable within 30 days with a 10% restocking fee.\" If a tag needs to carry parameters, use an annotation. If a tag is purely a yes-or-no flag, a marker is cleaner.\n\nThe last dimension, type hierarchy pollution, is more philosophical. Markers add supertypes. A `Book` that implements `Refundable, GiftWrappable, BulkOrderable, Cancellable` has five supertypes including `Object`. That's visible in IDE type hierarchies, in `getClass().getInterfaces()`, and in any code that walks the supertype chain. Some teams find this clarifying; others find it noisy. An annotation is invisible to the type hierarchy.\n\n---\n\n# When the Marker Approach Is Wrong\n\nMarkers aren't free, and there are situations where they're the wrong choice. Three patterns are common.\n\n### When You Need Metadata\n\nA marker is a single bit of information: \"this class supports X.\" If parameters need to be attached (a refund window, a tax rate, a priority level), the marker fails immediately. Extending the interface with constants is tempting, but constants in interfaces are public, inherited, and shared by every implementer. A per-class refund window cannot be stored on an interface.\n\nThis is where annotations win cleanly. `@Refundable(windowDays = 30)` is the right shape for parameterized metadata.\n\n### When the Tag Is About a Method, Not a Class\n\nMarkers apply to a whole class. To tag a single method (say, \"this method is the entry point\" or \"this method should be retried on failure\"), an annotation is required. There's no way to mark one method of a class with an interface.\n\nAnnotations have `@Target(ElementType.METHOD)`, which is the standard way to tag individual methods, fields, or parameters.\n\n### When the Tag Is About External Use, Not Internal Type\n\nFrameworks like Spring, Hibernate, JUnit, and Jackson all use annotations heavily because the framework reads them at startup or via reflection without the class needing to participate in any type hierarchy. If the consumer of a tag is an external tool that scans classes, annotations are usually the right answer. The tool doesn't need to know about the type system.\n\nA marker interface effectively says \"this class has this capability for in-process code that knows about this interface.\" An annotation says \"this class has this attribute that any tool can read.\"\n\n---\n\n# What Effective Java Says\n\n*Effective Java* (Joshua Bloch's book) has long been the standard reference for Java design decisions. Item 41 in the third edition (originally Item 37 in the second edition) addresses marker interfaces directly. The short version of Bloch's argument is:\n\n1. Marker interfaces define a type that allows compile-time checking. Annotations don't.\n2. Marker interfaces can be targeted more precisely. An annotation can apply to any class; a marker interface can be required as a parameter type, which prevents misuse at compile time.\n3. Annotations win when you need metadata or method-level targeting.\n4. The two are complementary, not substitutes. Use markers when you need a type. Use annotations when you need metadata.\n\nThe recommendation hasn't changed much since 2008. The rise of annotation-driven frameworks has made annotations the default in most modern Java code, but the type-system advantage of markers is still real, and `Serializable`, `RandomAccess`, and `Cloneable` aren't going anywhere.\n\nPractical guidance:\n\n- If the tag is consumed by an external framework via reflection (Spring beans, JUnit tests, Jackson serialization config), use an annotation.\n- If the tag needs to carry parameters, use an annotation.\n- If the tag is checked in application code with `instanceof` and compile-time enforcement at API boundaries matters, use a marker interface.\n- For tagging a method or a field, use an annotation; markers don't apply.\n- For tagging classes that the JVM itself reads (`Serializable`, `Cloneable`), the choice was made decades ago.\n\n---\n\n# A Historical Note: Why So Many Markers Live On\n\nMarker interfaces are older than annotations by about ten years. `Serializable` shipped in Java 1.1 (1997). `Cloneable` was in 1.0. `Remote` arrived in 1.1 with RMI. `RandomAccess` came in 1.4 (2002). Annotations didn't exist until Java 5 (2004).\n\nIf annotations had existed in 1997, some of those interfaces might have been annotations instead. `Serializable` is the strongest candidate, because the type-system role it plays is mostly \"permission to write to a stream,\" and that's something a `@Serializable` annotation could express well enough. `RandomAccess`, on the other hand, is exactly the kind of tag that benefits from being a type: the `Collections.binarySearch` algorithm needs the compile-time guarantee that any `List & RandomAccess` is fast to index into.\n\nThe JDK can't remove these interfaces now. Too much code depends on them. So they stay, and they remain the canonical examples of the pattern. New JDK code added since Java 5 has generally used annotations instead. `@FunctionalInterface`, `@Override`, `@SafeVarargs`, `@SuppressWarnings`, `@Deprecated` are all annotations that could have been markers in an alternative history.\n\nThe takeaway is that markers are a historically grounded pattern with a real (smaller) niche in modern code. The reflex to use an annotation first is correct most of the time. The reflex to reject markers entirely is a mistake. When a compile-time-checkable type tag is needed, the marker is appropriate, and that situation still comes up.","pageType":"java"}

Marker Interfaces

Get Premium