Marker Interfaces

A marker interface is an interface with no methods at all. It carries no behaviour and declares no contract beyond the type itself, so its whole purpose is to tag a class. The type check is the interface, and the semantics come from what the code does when the check succeeds.

public class Main {
    public static void main(String[] args) {
        Order o = new Order();
        System.out.println(describe(o));
    }

    static String describe(Object o) {
        if (o instanceof Auditable) {
            return "auditable record";
        }
        return "plain object";
    }
}

interface Auditable { }

class Order implements Auditable { }

The example tags an order as auditable and then checks for that tag at run time. The describe method returns a different result for a tagged object than for an untagged one, and the output shows the tagged branch being taken. No method had to be implemented for the tag to carry meaning.

The pattern has been used for decades. Serializable-like tags, a cacheable marker, a traceable marker. The idea is to let a general algorithm ask a question about an object without needing to know its concrete class.

The drawback is that the meaning of the tag is only in the head of whoever reads the code that checks for it. There is no method to document, no name that explains the behaviour, and nothing that tells you which classes are supposed to carry it. The class that implements the marker gains no visible capability.

That weakness is why annotations largely replaced markers. An annotation can carry metadata, is visible in the source at the point of use, and can be checked reflectively. The marker interface is still perfectly valid Java and still appears in older code and in a few frameworks, so it is worth recognising.

Annotations carry more information. A marker says only that a type is in a category, whereas an annotation can hold data, be placed on methods and fields as well as types, and be configured with parameters. The framework reads them reflectively and can act on the data, not just on the presence of the tag.

They are also more visible. When you see a class in the source with a marker interface, the class declaration tells you it is tagged but not why. An annotation usually has a name that says something, and it sits right next to the class it describes, so a reader encounters it in context rather than having to search the codebase for whoever checks for it.

Annotations are also more flexible about targets. An annotation can go on a method, a field or a parameter, which lets frameworks express things like a method being transactional or a field being serialised. A marker interface can only tag a whole type, so a single class that needs two different treatments in two different subsystems cannot express that.

The case for keeping markers is that they are ordinary types, so they work with the ordinary type system: a method can take a parameter of the marker type, and the compiler enforces the constraint with no reflection at all. If your check is a compile-time contract rather than a runtime hint, a marker interface is arguably the better tool even today.