Dynamic Method Dispatch in Java: Runtime Binding Explained

Every virtual call is resolved in two stages, and the table below is worth memorising because most misunderstandings come from conflating them.

Note that the first two are decided entirely by types you can read in the source, and the third is the only one that depends on a value.

public abstract class PaymentProcessor {
    public void process(String amount) {
        System.out.println("processing generic " + amount);
    }
}public class StripeProcessor extends PaymentProcessor {
    @Override public void process(String amount) {
        System.out.println("processing stripe " + amount);
    }
}public class Checkout {
    public static void pay(PaymentProcessor processor, String amount) {
        processor.process(amount);
    }
}

Given the call processor.process(amount), the compiler first reads the declared type of processor, which is PaymentProcessor. It finds process(String) there, confirms visibility, and emits a call. It does not inspect the object, because at that point the object may not exist yet.

At runtime the JVM performs the real selection:

• It loads the value sitting in the local variable, which is a reference.
• It follows the reference to the object on the heap.
• It reads the class recorded in that object header, here StripeProcessor.
• It looks up process(String) in that class's method table, following the inheritance chain upward only if the class itself does not define it.
• It invokes that implementation.

The lookup walks upward, never downward. If PremiumProcessor extends StripeProcessor but does not override process, the inherited StripeProcessor implementation runs.

Dispatch picks the implementation, but the compiler still uses the declared type for two things: deciding that the method is callable at all, and deciding which overload applies.

PaymentProcessor ref = new StripeProcessor();
ref.process("125.00");
// legal, the compiler found process on the type
ref.refund();
// COMPILE ERROR, StripeProcessor cannot widen the type

So dispatch does not remove the need for a correctly typed reference. It only removes the need for one that names the exact runtime class.

Overload selection is a good illustration, because it stays entirely at compile time even when overrides are in play.

public class PaymentProcessor {
    public void process(String amount) {
        System.out.println("string " + amount);
    } public void process(String amount, boolean urgent) {
        System.out.println("urgent " + amount);
    }
}public class StripeProcessor extends PaymentProcessor {
    @Override public void process(String amount) {
        System.out.println("stripe " + amount);
    }
}

PaymentProcessor ref = new StripeProcessor();
ref.process("125.00");
// stripe 125.00, the override wins at runtime
ref.process("125.00", true);
// urgent 125.00, the child has no such method

The second call picks the two-argument overload at compile time and, finding no override for it, ends up invoking the inherited parent version.

This is the part beginners most often get wrong. Four categories are bound at compile time and ignore the runtime type entirely.

Fields are the sharpest edge. A child may declare a field with the same name and a different value, and the reference type decides which one you read.

public class PaymentProcessor {
    protected String gateway = "generic";
}public class StripeProcessor extends PaymentProcessor {
    protected String gateway = "stripe";
    // a separate field, not an override
}StripeProcessor stripe = new StripeProcessor();
PaymentProcessor ref = stripe;
System.out.println(stripe.gateway);
// stripe
System.out.println(ref.gateway);
// generic

Both lines read a real field on the same object. The difference is purely the type of the expression used to reach it, which is why field hiding is confusing and why private fields with accessors are the usual advice.

Static methods behave the same way, as shown in the static methods topic.

Calling super.method() looks like it should still dispatch, but it cannot, because its entire purpose is to reach the parent implementation specifically.

public class StripeProcessor extends PaymentProcessor {
    @Override public void process(String amount) {
        super.process(amount);
        // explicitly the parent version
        System.out.println("logged the override");
    }
}

The compiler knows exactly which parent method is meant, so it emits a direct, non-virtual call. This is why recursion is impossible here and why this pattern is the supported way to extend rather than replace parent behaviour.

This is the one most likely to cause a real bug. A constructor may call an overridable method, and the child version will run, before the child has finished initialising.

public class PaymentProcessor {
    protected String gateway = "generic";
    public PaymentProcessor() {
        describe();
        // dispatched to the child, during construction
    } public void describe() {
        System.out.println("gateway " + gateway);
    }
}public class StripeProcessor extends PaymentProcessor {
    protected String gateway = "stripe";
    @Override public void describe() {
        System.out.println("stripe gateway " + gateway);
    }
}

new StripeProcessor();
// prints: stripe gateway null

Why null rather than stripe? Because the child field initialiser runs after the parent constructor completes. The object already reports itself as a StripeProcessor, so dispatch reaches the child override, but the child fields are not yet assigned.

Looking up a method by searching the class hierarchy on every call would be slow. Instead each class is prepared with a table of virtual method slots, often called a vtable, holding pointers to the concrete implementations.

Dispatch becomes a single indexed read: take the class pointer from the object header, index its table, and call what it finds. When a class overrides a method, the copying step simply leaves the child pointer in that slot, which is why no per-call searching is needed.

The JIT compiler then goes further. When a call site only ever sees one receiver class, a technique called monomorphic inlining, it can inline that implementation and remove the lookup entirely. When it regularly sees exactly two classes, bimorphic inlining, it keeps a fast two-way test. Beyond that it usually falls back to the full table lookup. This is why a hot loop that dispatches across dozens of classes performs worse than one over a handful.

Dispatch is not limited to classes. An interface reference selects the implementation just as a class reference does, including for default methods.

public interface Priced {
    String channel();
    default String summary() {
        return "channel=" + channel();
    }
}public class StripeProcessor implements Priced {
    @Override public String channel() {
        return "stripe";
    }
}Priced priced = new StripeProcessor();
System.out.println(priced.summary());
// channel=stripe

The interesting part is the nested call. summary() runs as a default method, then internally calls channel(), and that call dispatches to the implementation. A single invocation can therefore contain more than one runtime decision.

The interfaces topic covers the resolution order when a class inherits defaults from several interfaces.

The real payoff is that a list declared with a supertype element can hold unrelated subtypes, and each element still dispatches correctly without the loop knowing anything about concrete types.

List<PaymentProcessor> processors = List.of( new PayPalProcessor(), new StripeProcessor());
for (PaymentProcessor processor : processors) {
    processor.process("125.00");
}

The compiler checks process against PaymentProcessor once. Each iteration then makes its own runtime decision, which is precisely why you can add a new processor later without touching the loop.

Ordinary dispatch resolves against the static type at compile time and the object type at runtime. Reflection discards the static type and resolves everything at runtime, which is what makes frameworks able to call methods a compiler never saw.

Method method = PaymentProcessor.class.getMethod("process", String.class);
Object result = method.invoke(new StripeProcessor(), "125.00");
System.out.println("returned " + result);

Here the lookup starts from PaymentProcessor.class, finds the slot, and then dispatches to StripeProcessor.process because that is the receiver. The reflection topic covers the performance cost, which is substantial compared with a virtual call.

Frequently Asked Questions

What exactly is dynamic method dispatch?

It is the rule that a call to an overridable instance method executes the implementation belonging to the runtime class of the receiver, rather than the one on the type of the variable. The variable type only has to be a supertype. It is the mechanism that makes an Animal reference able to run a Dog method.

When does the JVM decide which method to run?

At the moment the instruction executes, not when the class is compiled. The compiler emits the call but cannot know the object yet. At runtime the JVM reads the class from the object header and resolves the matching implementation, so the same line of code can produce different behaviour on different runs.

Are fields dispatched dynamically?

No. A field reference is bound to the declared type of the expression, so a supertype reference reads the parent field even when the object is a subclass with its own field of the same name. Only method behaviour dispatches. This asymmetry is the usual reason field hiding is discouraged in favour of accessors.

What happens if a subclass does not override the method?

The JVM climbs the inheritance chain and uses the nearest ancestor that defines it. So a class three levels deep with no override still runs the grandparent implementation, and callers never need to know which level supplied it. Dispatch always moves toward the most specific definition, never back down.

Does overloading work with dynamic dispatch?

Overload selection is finished at compile time, using the declared types of the arguments, and dispatch only applies afterwards. If the chosen overload is overridden in the subclass, the subclass version runs. If it is not overridden, the inherited parent version runs, which is why a child can add overloads without disturbing the ones it inherits.

Why should overridable methods never be called from a constructor?

Because the child override runs before the child initialisers have executed, so it can read fields that are still null or zero. The object already reports its final class, so dispatch succeeds, but the state it depends on does not exist yet. Make such methods final, or defer the call until after construction.

Is reflection the same as dynamic dispatch?

No. Ordinary dispatch keeps a compile-time link to a statically known method and resolves only the implementation at runtime. Reflection discards the compile-time link entirely and resolves the name, the parameters, and the implementation all at runtime. That extra flexibility is why frameworks depend on it, and it is also why it costs considerably more than a virtual call.

Does dispatch work through an interface reference?

Yes. An interface reference selects the implementing class exactly as a class reference does, and default methods dispatch as well. A default method that calls an abstract method produces two separate runtime decisions in one invocation, one for each method.

Is dynamic dispatch slow?

Not in practice. A virtual call is an indexed table lookup rather than a search, and the JIT compiler usually removes it entirely for a call site that only ever sees one receiver class. Performance problems appear when a single hot call site sees a very large number of distinct types, since the compiler can no longer specialise it.