Expando and MetaClass

Analogy categoryAnalogies

Expando: Dynamic Bean-Like Objects

Expando is a Groovy class (groovy.util.Expando) that behaves like a dynamic bean: you can assign arbitrary properties to an instance at runtime, and if you assign a closure to a property, calling that property name as a method invokes the closure. This makes Expando useful for quick, ad-hoc objects — building a lightweight data holder or stub object in a test without first declaring a class. Because Expando doesn't require you to define a class upfront, it trades static structure for flexibility, which is ideal for prototyping or one-off scripting tasks but risky for long-lived production code where typos in property names fail silently at runtime rather than at compile time.

🏏

Cricket analogy: A franchise in the IPL auction can sign an uncapped player mid-season and instantly add them to the playing XI without rewriting the whole squad list, much like an Expando object lets you bolt on a new property or method to a single instance without redefining its class.

ExpandoMetaClass: Extending Any Class at Runtime

Where Expando creates new dynamic objects, ExpandoMetaClass modifies the metaClass of an existing class — including JDK classes you don't own, like String or Integer — to add new methods, properties, or even static methods and constructors, visible to every instance of that class (or, if you target metaClass directly on one object, to only that instance). This is Groovy's built-in mechanism for what other languages call monkey-patching or open classes: String.metaClass.shout = { -> delegate.toUpperCase() + '!' } genuinely adds a shout() method usable on any String in the running JVM from that point forward.

🏏

Cricket analogy: The ICC amending the official Laws of Cricket mid-season to add a new dismissal rule changes how every match is officiated from that point on, similar to how ExpandoMetaClass modifying a class adds behavior visible to every instance from that point forward.

groovy

// Add a method to every Integer instance
Integer.metaClass.isPrime = {
    def n = delegate
    if (n < 2) return false
    (2..Math.sqrt(n).toInteger()).every { n % it != 0 }
}

println 7.isPrime()   // true
println 10.isPrime()  // false

// Add a method to just ONE String instance
def greeting = "hello"
greeting.metaClass.shout = { -> delegate.toUpperCase() + "!" }
println greeting.shout()   // HELLO!

def other = "hi"
// other.shout()  // MissingMethodException - only 'greeting' got the change

Global vs Per-Instance MetaClass Changes

Changes made via SomeClass.metaClass.newMethod = {...} affect every instance of that class application-wide from that point forward, which is powerful but dangerous if two libraries both patch the same class differently. Per-instance changes, made by first calling ExpandoMetaClass.enableGlobally() (needed in older Groovy versions before per-instance metaclasses were default) and then assigning obj.metaClass = new ExpandoMetaClass(...) or simply obj.metaClass.newMethod = {...} directly on one object, are scoped to that single object and don't leak elsewhere. Registering a custom metaClass via GroovySystem.metaClassRegistry.setMetaClass(SomeClass, customMetaClass) is the lowest-level way to control this, useful for frameworks that need to intercept all calls to a class.

🏏

Cricket analogy: A stadium-wide PA announcement reaches every fan in the ground, while a single coach's whispered instruction reaches only one player on the bench, similar to a class-level metaClass change reaching every instance versus a per-instance change reaching just one object.

Global metaClass changes to widely used classes like String or Object are visible from every thread and every part of the application the moment they're applied, so they should generally be set once during application startup, not scattered through business logic where their effect becomes hard to trace.

Practical Use Cases and Caveats

The most common legitimate uses of ExpandoMetaClass are in testing (stubbing out a method on a domain class temporarily for one test, then resetting the metaClass in a teardown), and in Grails, which relies heavily on runtime metaprogramming to inject dynamic finders like Book.findByTitle() onto GORM domain classes without those methods being explicitly written anywhere. However, metaClass changes are invisible to @CompileStatic code (the compiler can't see a method added at runtime, so it will fail to compile a call to it), they don't survive class reloading cleanly in all contexts, and unrestrained monkey-patching of shared classes across a large codebase quickly becomes a debugging nightmare because a method's implementation is no longer where the class definition says it is.

🏏

Cricket analogy: A team using a substitute fielder rule only for the duration of a single match, then reverting to the normal XI afterward, mirrors stubbing a method via metaClass for one test and resetting it in teardown.

Avoid patching core JDK classes like String, Integer, or Object in production application code outside of a well-contained testing or framework layer. A method added via metaClass to a heavily used class is effectively global mutable state, and two unrelated pieces of code patching the same method name will silently overwrite each other with no compiler warning.

Expando (groovy.util.Expando) creates dynamic bean-like objects; assigning a closure to a property makes it callable as a method.
ExpandoMetaClass modifies an existing class's metaClass to add methods/properties/constructors, including on JDK classes you don't own.
Class-level metaClass changes (SomeClass.metaClass.x = ...) affect every instance application-wide from that point on.
Per-instance metaClass changes (obj.metaClass.x = ...) only affect that single object.
GroovySystem.metaClassRegistry gives the lowest-level control over which metaClass a class uses.
@CompileStatic code cannot see methods added dynamically via metaClass and will fail to compile calls to them.
Grails' dynamic finders (e.g. findByTitle) are a real-world example of ExpandoMetaClass powering a production framework.