Interfaces & Abstract Classes

Marker & Sealed Interfaces

15 min Lesson 9 of 14

Marker & Sealed Interfaces

Not every interface exists to describe behaviour through method contracts. Two specialised categories — marker interfaces and sealed interfaces — solve fundamentally different problems: one attaches metadata to a class, the other restricts which classes are permitted to implement an interface at all. Both patterns appear in real Java code, so understanding when and why to use each is essential.

Marker Interfaces

A marker interface has no methods. Its only purpose is to tag a class so that other code — typically a framework or the JVM itself — can detect the tag at runtime using instanceof or reflection.

// The classic JDK example
public interface Serializable {
    // nothing here — the tag is the entire contract
}

When the JVM's serialisation mechanism receives an object, it checks obj instanceof Serializable before proceeding. If the class was not tagged, a NotSerializableException is thrown. The interface carries no method signature; all the real serialisation logic lives in the JVM and in ObjectOutputStream.

Other well-known JDK marker interfaces include Cloneable (enables the protected Object.clone() copy mechanism) and RandomAccess (signals that a List supports O(1) indexed access, allowing algorithms to pick a faster path).

Writing Your Own Marker Interface

You can define a marker interface to attach semantic meaning to classes in your own application:

// Marks a command as safe to replay after a system failure
public interface Idempotent { }

public class PlaceOrderCommand implements Idempotent {
    private final String orderId;
    public PlaceOrderCommand(String orderId) { this.orderId = orderId; }
    public String getOrderId() { return orderId; }
}

public class CommandBus {
    public void execute(Object command) {
        if (command instanceof Idempotent) {
            System.out.println("Safe to retry: " + command.getClass().getSimpleName());
        }
        // ... dispatch the command
    }
}

Modern alternative — annotations. Since Java 5, annotations such as @Idempotent can carry the same metadata with less ceremony and can additionally hold attributes (e.g. @Idempotent(retries = 3)). For new code, prefer annotations over marker interfaces unless you genuinely need a type-system check via instanceof or a generic bound like <T extends Idempotent>.

Sealed Interfaces (Java 17)

A sealed interface explicitly lists every class (or interface) that is permitted to implement it. Any class not on the list is a compile-time error. This gives the library author precise control over the type hierarchy.

// Only Triangle, Circle, and Rectangle may implement Shape
public sealed interface Shape
    permits Triangle, Circle, Rectangle { }

public final class Triangle implements Shape {
    public final double base, height;
    public Triangle(double base, double height) {
        this.base = base; this.height = height;
    }
}

public final class Circle implements Shape {
    public final double radius;
    public Circle(double radius) { this.radius = radius; }
}

public final class Rectangle implements Shape {
    public final double width, height;
    public Rectangle(double width, double height) {
        this.width = width; this.height = height;
    }
}

Each permitted class must be declared in one of three ways:

final — closes the hierarchy completely; no further subclassing.
sealed — the permitted class itself restricts its own subtypes.
non-sealed — reopens the hierarchy; anyone may extend or implement this class.

Why Sealing Matters: Exhaustive Pattern Matching

The real payoff of sealed interfaces is with switch expressions introduced in Java 17+. Because the compiler knows every possible implementor, it can verify that your switch is exhaustive — no default branch required:

public static double area(Shape shape) {
    return switch (shape) {
        case Triangle t  -> 0.5 * t.base * t.height;
        case Circle c    -> Math.PI * c.radius * c.radius;
        case Rectangle r -> r.width * r.height;
        // No default needed — the compiler knows there are no other shapes
    };
}

If you later add a Pentagon to the permits list, every switch on Shape that is missing the Pentagon case becomes a compile error — the compiler guides you to every call site that needs updating.

Sealed interfaces pair naturally with records. Records are implicitly final, so they satisfy the sealed contract perfectly:

public sealed interface Shape permits Triangle, Circle, Rectangle { }
public record Triangle(double base, double height) implements Shape { }
public record Circle(double radius)               implements Shape { }
public record Rectangle(double width, double height) implements Shape { }

This combination is the idiomatic Java 17+ way to model algebraic data types (similar to union types or enums with data).

Sealed Interfaces vs Enums

An enum is perfect when each variant carries no extra data and you want a fixed set of constants. A sealed interface is the right choice when different variants carry different data shapes — for example Triangle has two measurements while Circle has one. The two features complement each other and can even be combined: an enum can implement a sealed interface to become one of its permitted variants.

All permitted types must be in the same package (or module). The compiler enforces this so that the full set of subtypes is always visible in one place. Spreading sealed hierarchies across packages breaks the guarantee and will not compile.

Summary

Marker interfaces attach a tag to a class that runtime code can detect via instanceof; the JDK uses this for Serializable, Cloneable, and RandomAccess. For new code, annotations are often a cleaner alternative unless you need a type-system constraint. Sealed interfaces, added in Java 17, restrict who may implement an interface, turning the compiler into a guardian of your type hierarchy and enabling exhaustive pattern matching in switch expressions — a powerful tool for modelling closed sets of related types.