Interfaces

What it is and why it exists

A Java interface is a reference type that cannot be instantiated directly. It names a set of operations without requiring every implementation to share a superclass or object layout. A class can implement several interfaces, and an interface can extend several interfaces, so behavior contracts do not have to follow the single-inheritance class hierarchy.

Java uses nominal typing . A class does not implement an interface merely because it happens to have methods with matching names; source code must establish the relationship through implements or inheritance. Callers therefore need not guess whether a matching signature is accidental or intended to fulfill the contract.

An interface type enables subtype polymorphism . A constructor that accepts ShippingRule, for example, can receive a flat-rate rule, a weight-based rule, or a test double without knowing their classes. Instance calls still dispatch on the actual object at runtime; an interface reference is not a new wrapper around that object.

You meet interfaces in collections, comparators, listeners, service boundaries, and dependency injection. They work best for a capability that callers genuinely depend on, especially when unrelated classes can fulfill the same contract. When the design mainly needs shared instance state, a construction sequence, or protected helper code, an abstract class is usually more direct.

Method signatures leave important behavior unstated. Null rules, parameter units, return meanings, exceptions, thread-safety requirements, and side effects all belong to the contract. At a cross-team or public-library boundary, put those constraints in documentation and contract tests.

How it works

A class uses implements for an interface; an interface uses extends to combine other interfaces. A non-abstract class must implement the abstract instance methods it inherits unless a more specific default method already satisfies them. An interface variable can refer to any compatible instance, but it directly exposes only the members of its static type.

Interfaces have no constructors or instance fields. A field declaration is implicitly public static final, so it stores an interface-level constant reference; if that reference points to a mutable collection, the collection can still change. Putting a mutable object in an interface field creates public global state. The final reference does not make it safe.

Abstract and default methods are implicitly public; they cannot be protected or package-private. Static methods may be public or private, while private instance methods are callable only by the interface’s own instance methods. An implementation cannot reduce the visibility of a method it implements.

A default method has an instance method body and may call other instance methods or private instance helpers. It has no instance fields of its own, so its behavior can depend only on parameters, constants, and state the receiver exposes through the contract. Defaults fit convenience operations derived from existing primitives, not hidden new state requirements.

When several candidate instance methods meet, the compiler uses these rules to decide whether an explicit override is needed:

1. A concrete instance method in a class or superclass wins over an interface default.
2. When one interface is more specific than another, the subinterface declaration wins.
3. When unrelated interfaces provide conflicting defaults, the implementing class must override; its body may select a direct superinterface implementation with InterfaceName.super.method().

Static interface methods do not participate because subclasses and implementing classes do not inherit them. Call one through its declaring interface, such as Rule.parse(), and do not assume ConcreteRule.parse() exists. Private methods are likewise not inherited or callable from an implementation.

A functional interface has one abstract method contract, also called a single abstract method (SAM) interface. Default, static, and private methods do not add to that count, and methods corresponding to public instance methods of Object have a special exclusion. @FunctionalInterface is optional, but it makes the compiler reject a declaration as soon as the contract no longer qualifies.

Lambda expressions and method references need a target type; the target functional interface determines their parameter and return types. This adaptation of a function value to a SAM interface instance is often called SAM conversion . The lambda implements only the function method, while the interface’s default methods remain available.

Examples

These three programs start with substitute implementations, resolve default-method conflicts, and then compose a functional interface. Their output was produced locally with OpenJDK 21.0.12 using javac --release 21 -Xlint:all; the syntax and interface rules used here remain valid in the target Java 25.

Isolating callers from implementations

The quoting function accepts only ShippingRule. Two record classes hold different data and implement the same operation, while a default method derives a diagnostic name from the actual class.

List.<ShippingRule>of(...) explicitly views the two different records as one interface type. Calls in the loop still reach each record’s feeInCents() implementation, while label() reuses the interface default. The caller does not need an instanceof branch for each pricing class.

This interface does not yet constrain rates to be nonnegative, and the third experiment exposes that gap. The domain contract must decide whether the record constructor or the rule method owns that check. Hiding an implementation behind an interface does not validate object state by itself.

Resolving default precedence and conflicts

Child inherits both a superclass method and an interface default, so the class method wins. Transfer implements two unrelated interfaces and must override their conflicting method explicitly.

public class DispatchRules {
    static class Parent {
        public String source() {
            return "class";
        }
    }

    interface Named {
        default String source() {
            return "interface";
        }
    }

    static final class Child extends Parent implements Named {}

    interface Fast {
        default String mode() {
            return "fast";
        }
    }

    interface Safe {
        default String mode() {
            return "safe";
        }
    }

    static final class Transfer implements Fast, Safe {
        @Override
        public String mode() {
            return Fast.super.mode() + "+" + Safe.super.mode();
        }
    }

    public static void main(String[] args) {
        System.out.println(new Child().source());
        System.out.println(new Transfer().mode());
    }
}

class
fast+safe

Deleting Transfer.mode() causes a compile-time error instead of an arbitrary runtime choice. Fast.super.mode() can name only an allowed direct superinterface; it does not make an arbitrary ancestor interface callable like a static utility class.

Child does not override source(), but the concrete superclass method already satisfies the Named contract. The superclass does not even have to declare implements Named. The subclass declaration establishes the interface relationship as long as the inherited method has the right signature and visibility.

Composing a functional interface

Rule<T> has only one abstract method, test(), so a lambda can implement it. The default and() method returns another Rule<T>, while a static method supplies a named base rule.

import java.util.Objects;

public class ValidationPipeline {
    @FunctionalInterface
    interface Rule<T> {
        boolean test(T value);

        default Rule<T> and(Rule<? super T> other) {
            Objects.requireNonNull(other);
            return value -> test(value) && other.test(value);
        }

        static Rule<String> notBlank() {
            return value -> value != null && !value.isBlank();
        }
    }

    public static void main(String[] args) {
        Rule<String> accountName = Rule.<String>notBlank()
                .and(value -> value.startsWith("acct-"));

        System.out.println(accountName.test("acct-alice"));
        System.out.println(accountName.test("   "));
        System.out.println(accountName.test("guest"));
    }
}

true
false
false

and() short-circuits. A blank string fails the first rule, so startsWith() never runs; null also stays out of the second rule. That behavior is part of the combinator’s contract and deserves tests just as much as its parameter types.

Adding a second, non-equivalent abstract method to Rule breaks both the @FunctionalInterface declaration and every lambda target. Adding a default or static method preserves the function descriptor, though a new default can still clash with another interface.

Keeping a static factory and private helper in the interface

A static factory can hide a small implementation behind the interface, while a default method can reuse private helper logic. Neither method adds to a functional interface’s abstract-method count.

import java.util.Locale;
import java.util.Objects;

public class InterfaceHelpers {
    @FunctionalInterface
    interface AccountId {
        String raw();

        default String normalized() {
            return normalize(raw());
        }

        static AccountId of(String raw) {
            Objects.requireNonNull(raw);
            return () -> raw;
        }

        private static String normalize(String raw) {
            return raw.strip().toLowerCase(Locale.ROOT);
        }
    }

    public static void main(String[] args) {
        AccountId account = AccountId.of(" ACCT-42 ");
        System.out.println(account.normalized());
        System.out.println(AccountId.of(" JOB-7 ").raw().strip());
    }
}

acct-42
JOB-7

of() must be called through AccountId because implementations do not inherit static interface methods. normalize() is callable only inside the interface, so defaults can share implementation without expanding the API visible to implementing classes or callers.

Pitfalls

Treating a mutable object as an interface constant

Fix: expose only genuinely immutable values from an interface, and pass configuration and state into implementation constructors. If a constant exists only for interface implementation code, keep it behind a private static method or a separate internal class instead of expanding the public API.

Designing a large interface callers cannot fulfill

Fix: split capabilities around what callers need and apply the interface segregation principle . Depend on the smallest interface in method parameters; when a caller genuinely needs a capability group, compose it with a subinterface.

Hiding failure policy in a default method

Fix: use defaults to combine existing operations while preserving their failure semantics. The calling layer that owns the context should decide network retries, authorization failure, and transaction rollback. Give ordinary absence an explicit result type instead of swallowing unexpected exceptions.

Assuming a default method is automatically backward compatible

Fix: run compatibility tests with old implementation binaries, then cleanly rebuild every implementation and caller. Check same-name methods, return types, exceptions, and side effects. A public interface change needs release notes and a migration path.

Treating a static method as inherited

Fix: qualify a static method with its declaring interface. If construction must vary by implementation type, use a separate factory interface, constructors, or a registry instead of trying to simulate polymorphic dispatch with static methods.

Further reading

• Java Language Specification 25: Interface Members
• Java Language Specification 25: Inheriting Methods with Override-Equivalent Signatures
• Java Language Specification 25: Functional Interfaces
• Java Language Specification 25: Interface Method Evolution
• Dev.java: Defining Interfaces