Dynamic Method Dispatch

Analogy categoryAnalogies

What Is Dynamic Method Dispatch?

In Java, method overload resolution happens at compile time: the compiler looks at the declared (static) type of each argument and picks the matching overload before the program ever runs. Groovy, by default, defers this decision to runtime. When you call a method on an object, Groovy's dynamic dispatch mechanism inspects the actual runtime class of the receiver and its arguments, then walks the metaclass hierarchy to find the most specific matching method. This is why Groovy is described as supporting multimethods (also called multiple dispatch) for method arguments, even though the JVM itself only natively supports single dispatch on the receiver.

🏏

Cricket analogy: A cricket captain doesn't decide the bowling change before the toss based on the team sheet alone — they watch how the pitch is behaving during the actual over, like MS Dhoni reading conditions live, and pick the bowler suited to that real-time situation rather than a pre-match plan.

Multimethods: Dispatch on Argument Types

Groovy extends dynamic dispatch beyond the receiver to method arguments as well, a feature it calls multimethods. Given two overloaded methods, process(String s) and process(Object o), if you call process(value) where value is declared as Object but actually holds a String at runtime, Groovy will invoke process(String s) — the overload matching the real runtime type. Java, by contrast, would statically bind to process(Object o) because that's the declared type of the variable. This makes Groovy well suited for visitor-style patterns and polymorphic collection processing without explicit instanceof checks, but it also means the chosen overload can only be determined by actually running the code.

🏏

Cricket analogy: A fielding coach assigning catching drills doesn't group players by the position listed on the team sheet; they assign the actual drill based on whether the player is really a slip fielder or an outfielder that day, matching the drill to the real skill in front of them.

groovy

class Printer {
    void show(String s) { println "String: $s" }
    void show(Integer i) { println "Integer: $i" }
    void show(Object o) { println "Object: $o" }
}

def printer = new Printer()
def items = ["hello", 42, 3.14]   // declared as Object in the list

items.each { item ->
    printer.show(item)   // dispatch decided by runtime type of 'item'
}
// Output:
// String: hello
// Integer: 42
// Object: 3.14

The Role of MetaClass in Method Lookup

Every Groovy object carries a reference to a MetaClass, and it is this MetaClass — not a fixed vtable the way the JVM handles Java virtual calls — that Groovy's runtime consults to find the method to invoke. When you call obj.doSomething(args), the Groovy runtime calls invokeMethod on obj's metaClass, which searches declared methods, then category methods, then any methods added via ExpandoMetaClass, and finally falls back to methodMissing if nothing matches. This indirection is what makes Groovy's dispatch pluggable: you can swap out an object's metaClass at runtime to change how it responds to the same method call.

🏏

Cricket analogy: A DRS review doesn't just take the on-field umpire's word; it walks through a chain of checks — snickometer, ball-tracking, hot spot — before a final decision, similar to how a metaClass walks declared methods, categories, and methodMissing before settling on a result.

Because every dispatch goes through the metaClass lookup chain, calling the same method name repeatedly in a tight loop is measurably slower in dynamic Groovy than in compiled Java. Groovy caches call-site resolutions (via invokedynamic on modern JVMs) to reduce this cost, but it's still worth knowing where the overhead comes from before optimizing.

Static Compilation and Its Effect on Dispatch

Adding @CompileStatic to a class or method tells the Groovy compiler to resolve method calls at compile time, the same way javac does, bypassing the metaClass lookup chain entirely for calls it can prove statically. This delivers a significant performance boost and catches type errors earlier, but it also means multimethod-style dispatch on declared-Object arguments stops working the way it does in dynamic Groovy — the compiler picks the overload based on the declared type, not the runtime type. Mixing @CompileStatic and dynamic code in the same codebase is common, but you need to know which parts have opted out of dynamic dispatch.

🏏

Cricket analogy: A franchise that locks its entire batting order months before the tournament, refusing to adjust to form or pitch conditions, trades flexibility for predictability, similar to how @CompileStatic locks method resolution at compile time in exchange for speed and certainty.

Switching a class to @CompileStatic can silently change which overload gets called for code that relied on multimethod dispatch, since the compiler now binds by declared type instead of runtime type. Always re-test overload-sensitive code paths after adding @CompileStatic to an existing dynamic Groovy class.

Dynamic dispatch resolves which method implementation runs at runtime based on the actual object, not the declared/static type.
Groovy supports multimethods: overload resolution for arguments also happens dynamically, unlike Java's compile-time overload binding.
Every Groovy object's method calls route through its MetaClass, which searches declared methods, categories, ExpandoMetaClass additions, and methodMissing in order.
invokedynamic and call-site caching reduce, but don't eliminate, the runtime cost of dynamic dispatch.
@CompileStatic switches a class back to compile-time (static) method binding, gaining speed but losing multimethod behavior.
Mixed codebases commonly combine @CompileStatic hot paths with fully dynamic code elsewhere.
Re-test overload-sensitive logic whenever you add @CompileStatic to previously dynamic code.

Practice what you learned

1. In Groovy, given process(String s) and process(Object o), what determines which overload is called when the argument variable is declared as Object but holds a String at runtime (in dynamic, non-@CompileStatic code)?

2. What object does Groovy consult at runtime to determine which method implementation to invoke on a given object?

3. What is the primary effect of annotating a class with @CompileStatic?

4. What happens when Groovy's metaClass lookup chain finds no matching method for a call?

5. Why might overload resolution behavior change unexpectedly after adding @CompileStatic to a previously dynamic Groovy class?

Was this page helpful?

Groovy DSLs Explained