Interfaces in Java

Interviewers ask about interfaces at every level. A junior screen checks that you know the implicit modifiers and that a class can implement many interfaces. A senior round asks why Serializable has no methods, why ArrayList implements RandomAccess, what a constant interface is and why it's an anti-pattern, and whether calling through an interface is slower than calling through a class. The good news is that all of those answers come from one idea: an interface defines a type, and Java lets a class have many types.

For this lesson, we'll focus on what an interface declares and the modifiers the compiler adds for you, multiple implementation and interface inheritance, marker interfaces versus annotations, private interface methods, the constant interface anti-pattern, programming to an interface, and what invokeinterface costs at runtime.

01Picture it first: sockets on a wall

Think of the power sockets in a hotel room. The socket is the contract: a shape and a voltage. A phone charger, a laptop brick and a hair dryer are completely different devices, but each has a plug that fits, so the room works with all of them. The socket doesn't care what's on the other end. And one device can carry several plugs, like a travel adapter that fits both the wall and a USB port.

That's the relationship between interfaces and classes. The figure below shows one gateway class carrying three "plugs": FullGateway (which itself combines PaymentGateway and Refundable) and Auditable. Any code that needs one of those types can accept a StripeGateway.

Fig. 1

StripeGateway implements FullGateway and Auditable; FullGateway extends both PaymentGateway and Refundable, so a StripeGateway object can be passed anywhere any of the four interface types is expected

Notice two kinds of arrows. A class implements interfaces, and an interface extends other interfaces (as many as it likes). There's no arrow for state, because interfaces carry none. That's why Java can allow this "many parents" picture for interfaces while allowing only one superclass.

02Interfaces under the hood

public interface PaymentGateway {
    int MAX_RETRIES = 3;                                   // really: public static final
    String charge(String orderId, BigDecimal amount);      // really: public abstract
}

interface Refundable { void refund(String txnId); }
interface Auditable  { String auditTag(); }

interface FullGateway extends PaymentGateway, Refundable {}   // multiple interface inheritance

class StripeGateway implements FullGateway, Auditable {
    @Override public String charge(String orderId, BigDecimal amount) { return "txn-" + orderId; }
    @Override public void refund(String txnId) { /* call Stripe */ }
    @Override public String auditTag() { return "stripe"; }
}

PaymentGateway g = new StripeGateway();
System.out.println(g instanceof Refundable);   // prints: true
System.out.println(Modifier.toString(
    PaymentGateway.class.getField("MAX_RETRIES").getModifiers()));   // prints: public static final

Notice four things:

• Methods without a body are public abstract. Writing those words is legal but redundant. Writing protected or final on an interface method is a compile error.
• Fields are public static final, always. There's no way to declare an instance field in an interface, and every field needs an initialiser. The interface itself is implicitly abstract, and nested types inside it are implicitly public static.
• Implementations must be public. If StripeGateway writes String charge(...) without public, javac reports attempting to assign weaker access privileges; was public. That's the overriding rule from Access modifiers.
• instanceof sees every interface in the graph. g is declared as PaymentGateway, but the object is also a Refundable, FullGateway and Auditable. The variable's type limits what you can call; the object's class decides what it is.

What an interface can and can't contain

Since Java 9, an interface can hold more than signatures. The full list is: abstract methods, default methods (Java 8), static methods (Java 8), private and private static methods (Java 9), constants, and nested types. What it can never have is instance fields, constructors, instance initialiser blocks, or protected and final methods. Those all relate to per-object state or to controlling subclasses, which is the job of an abstract class.

private methods arrived with JEP 213 to solve a practical problem: two default methods that need the same helper. Before Java 9, the helper had to be a default or static method, which made it part of the public API. Now it stays hidden:

public interface PaymentGateway {
    int MAX_RETRIES = 3;

    String charge(String orderId, BigDecimal amount);

    default String chargeWithRetry(String orderId, BigDecimal amount) {
        for (int attempt = 1; ; attempt++) {
            try {
                return charge(orderId, amount);
            } catch (RuntimeException e) {
                if (attempt == MAX_RETRIES) throw e;
                logFailure(attempt, e);
            }
        }
    }

    private void logFailure(int attempt, RuntimeException e) {     // Java 9+: not part of the API
        System.out.println("attempt " + attempt + " failed: " + e.getMessage());
    }
}
// With a gateway that times out twice: prints "attempt 1 failed: timeout",
// "attempt 2 failed: timeout", then returns "txn-o-7"

A private interface method can't be abstract or default, and callers outside the interface can't see it. We cover the default-method rules properly in the next lesson.

Marker interfaces: a type with no methods

Serializable, Cloneable and RandomAccess declare zero methods. They exist so code can ask "is this object one of those?" and change behaviour:

• Serializable: ObjectOutputStream.writeObject checks instanceof Serializable and throws NotSerializableException if the check fails. Writing a plain Session object fails with java.io.NotSerializableException: Session.
• Cloneable: Object.clone() checks it and throws CloneNotSupportedException otherwise. The interface doesn't even declare clone(), which is one reason Effective Java calls it a broken design.
• RandomAccess: tells generic algorithms that get(i) is fast. Collections.binarySearch uses an indexed search for an ArrayList (true for instanceof RandomAccess) and an iterator-based search for a LinkedList (false), because get(i) on a linked list walks the nodes and would make binary search O(n log n).

Java 5 annotations can also mark things, so when do you pick which? A marker interface defines a type, so the compiler can check it: a method can take a Serializable parameter and reject everything else at compile time. An annotation can't do that, but it can mark methods, fields and packages (not only classes), can carry values (@Retention(RUNTIME), @Table(name = "orders")), and can be added without changing the type hierarchy. My rule: if you'd ever want a method parameter of that type, use a marker interface; otherwise use an annotation.

03Real world: programming to an interface

// Coupled: depends on a concrete class
class OrderService {
    private final HashMap<String, Order> store = new HashMap<>();
    ArrayList<Order> findByUser(String userId) { /* ... */ return new ArrayList<>(); }
}

// Programmed to interfaces: depends only on contracts
interface OrderRepository {
    Optional<Order> findById(String id);
    List<Order> findByUser(String userId);
    void save(Order order);
}

class OrderService2 {
    private final OrderRepository repo;                     // any implementation
    OrderService2(OrderRepository repo) { this.repo = repo; }

    List<Order> recentOrders(String userId) {              // return the interface type
        return repo.findByUser(userId);
    }
}

The second version is what "program to an interface, not an implementation" means. OrderService2 compiles against OrderRepository and List, so you can pass a JdbcOrderRepository in production, an InMemoryOrderRepository in tests, and a caching decorator later, without touching the service. Spring's dependency injection, JDBC's Connection and PreparedStatement, and the whole Collections framework are built on this idea. Declaring List<Order> orders = new ArrayList<>() instead of ArrayList<Order> orders is the everyday version of the same habit.

The diagram below shows the design shape I want you to picture when code is programmed to interfaces instead of concrete classes.

Fig. 2

OrderService depends on an OrderRepository interface while JDBC, in-memory and cached repositories can be swapped underneath without changing the service

04Advanced: what invokeinterface costs, and other edge cases

invokevirtual vs invokeinterface

A call through a class type compiles to invokevirtual, and a call through an interface type to invokeinterface. The difference matters because of how HotSpot lays out method tables. Every class has a vtable, where a method keeps the same index in every subclass, so dispatch is "load the receiver's class, load slot k, jump". Interfaces can't promise a fixed index, because a class can implement any combination of them in any order. So each class also has an itable: a small table of "interface → where its methods start" entries, followed by the method blocks.

The figure below compares the two lookups for a call site the JIT couldn't optimise.

Fig. 3

Two dispatch paths: invokevirtual loads the receiver class and reads a fixed vtable slot in one step, while invokeinterface loads the receiver class, scans the itable offset entries until it finds the interface, then reads the method at that interface's block plus an index

That scan sounds slow, and it's why "interfaces are slower" is a common interview claim. In practice the JIT rarely reaches it:

The place I have seen interface checks really hurt is instanceof and casts against an interface on a hot path across many threads. HotSpot answered those with a one-element "secondary super cache" per class, and threads checking against different interfaces kept overwriting it, causing cache-line ping-pong between cores. JDK 23 replaced that cache with a hashed lookup table (JDK-8180450). On Java 21, if a profiler shows heavy time in type checks of a hot class, this is the likely culprit.

Interface initialisation is lazy

A class's initialisation triggers its superclass's initialisation, but not its superinterfaces' (unless they declare default methods). Interface fields that aren't compile-time constants are only initialised when first used:

interface RegionConfig {
    String REGION = loadRegion();                      // not a compile-time constant
    static String loadRegion() { System.out.println("RegionConfig initialised"); return "ap-south-1"; }
}
class BillingService implements RegionConfig {
    static { System.out.println("BillingService initialised"); }
}

new BillingService();                        // prints: BillingService initialised
System.out.println(RegionConfig.REGION);     // prints: RegionConfig initialised, then ap-south-1

Quick rules that come up as follow-ups

05How to say it in the interview

When I ask about interfaces, I'm listening for whether you think of an interface as a type and a contract, not as "a class with empty methods". I want the implicit modifiers stated precisely, the modern member list (default, static, private), a good reason for marker interfaces, and a practical habit: declaring List, injecting a repository interface. Senior candidates can also explain why interface dispatch is cheap after JIT and when it isn't.

interface = type + contract, no instance state, no ctor
method (no body) → public abstract   field → public static final
+ default/static (8), private (9)    never protected/final
class implements A, B, C   interface extends A, B
impl methods must be public
markers: Serializable, Cloneable, RandomAccess → instanceof checks
marker iface = compile-time type; annotation = metadata, any element
constant interface = anti-pattern (API leak + inlined constants)
program to interface: List<Order> x = new ArrayList<>()
invokeinterface → itable scan, but inline cache / CHA → ~free