DevOps / Apache Groovy Interview questions

Apache Groovy is a dynamic, optionally-typed programming language for the Java Virtual Machine, designed to be highly compatible with Java syntax while adding features like closures, native list/map literals, and built-in markup building.

It compiles to standard JVM bytecode, so Groovy code can call Java libraries directly and vice versa, making it easy to adopt incrementally inside an existing Java codebase rather than requiring a full rewrite.

It's widely used for scripting, testing (via the Spock framework), and as the DSL foundation for build tools like Gradle and CI pipelines like Jenkins.

A closure is an anonymous, reusable block of code that can take parameters, return a value, and be assigned to a variable or passed around like any other object - Groovy's version of a first-class function.

Unlike a plain method, a closure captures variables from its surrounding scope at the point it's defined, so it can reference and even modify local variables from the context where it was created, even after that context has technically finished executing.

Closures are used pervasively throughout the GDK - most collection methods like each, collect, and find take a closure as their argument to define what happens per element.

A GString is Groovy's interpolated string type, written with double quotes, that lets you embed expressions directly inside the string using ${...} (or a simpler $variable shorthand for plain variable references).

Unlike a plain Java String, a GString is lazily evaluated - the embedded expression is only resolved to its current value when the GString is actually converted to a String, not necessarily at the moment it was written.

Single-quoted strings in Groovy remain plain, non-interpolated Java Strings, so choosing double versus single quotes is also a signal of whether interpolation is intended.

The safe navigation operator, written ?., lets you call a method or access a property on an object that might be null without throwing a NullPointerException - if the object is null, the whole expression short-circuits and simply evaluates to null instead of throwing.

It's especially useful for chained property access, like user?.address?.city, where any link in the chain could be null; without it, each step would need an explicit null check to avoid an exception.

It only guards against the object immediately to its left being null - a longer chain still needs ?. applied at each link where a null is genuinely possible, since the check doesn't automatically extend past where it's applied.

The Elvis operator, written ?:, is shorthand for returning a value if it's truthy, or a default otherwise - value ?: default is equivalent to the longer value ? value : default, without writing the checked value twice.

It's commonly used to provide fallback values, like name = inputName ?: "Unknown", where inputName being null or empty falls back to the default string.

It relies on Groovy Truth to decide whether the left-hand value counts as "present," so it treats not just null but also empty strings, empty collections, and zero as falsy, not only null specifically.

Groovy Truth is the set of rules Groovy uses to decide whether a value is treated as true or false in a boolean context (like an if statement), and it's broader than Java's - where only actual true/false values are valid.

Under Groovy Truth, null is false, an empty string or empty collection is false, zero is false, and a non-null, non-empty, non-zero value is generally true - so if (list) is true only when the list actually has elements.

This lets conditionals read more naturally (if (name) instead of if (name != null && !name.isEmpty())) but it's a common source of subtle bugs for developers coming from Java who expect only actual booleans to be evaluated.

def declares a variable, method, or field without specifying an explicit static type, letting Groovy infer or defer the type dynamically rather than requiring it upfront the way Java does.

A variable declared with def can be reassigned to a value of a completely different type over its lifetime, since its declared type is effectively Object unless narrowed by other means like static compilation checks.

def is optional in the sense that you can still declare an explicit type (like String name = "x") instead, and doing so where the type is known is generally considered better practice for readability and tooling support.

A GroovyBean is Groovy's simplified version of a JavaBean: declaring a field as a class property (without explicit private/getter/setter boilerplate) automatically generates a public getter and setter for it at compile time.

For example, class Person { String name } automatically gets getName() and setName(String) generated, without writing them by hand, while still behaving like a normal JavaBean to any Java code that calls those methods.

This removes a large amount of Java's characteristic boilerplate for simple data-holding classes, while still producing bytecode that's fully compatible with frameworks expecting standard JavaBean getter/setter conventions.

The spread operator, written *., applies a method call or property access to every element of a collection at once, returning a new collection of the results - shorthand for calling collect with that same operation.

For example, people*.name is equivalent to people.collect { it.name } - both return a list of every person's name without writing an explicit loop or closure.

It can also be used when calling a method with a list of arguments, spreading a list into individual positional arguments, which is a related but distinct use of the same spread syntax family.

An AST (Abstract Syntax Tree) transformation is code that runs during Groovy's compilation process to modify the program's structure before it's turned into bytecode - effectively generating or altering code automatically at compile time rather than at runtime.

Groovy ships many built-in AST transformations as annotations, like @ToString, @EqualsAndHashCode, and @Builder, each injecting the corresponding generated methods into a class without the developer writing that boilerplate by hand.

Because transformations happen at compile time, the generated code is part of the actual compiled bytecode with no runtime reflection overhead, unlike some annotation-processing approaches that rely on runtime inspection instead.

@CompileStatic instructs the Groovy compiler to type-check a class or method at compile time and generate optimized, statically-dispatched bytecode, similar to how Java itself compiles, instead of Groovy's normal dynamic method dispatch.

This catches certain type errors at compile time rather than only at runtime, and it generally improves performance since the compiler can resolve method calls directly instead of going through Groovy's dynamic runtime dispatch machinery on every call.

The tradeoff is losing some of Groovy's dynamic features, like freely adding methods at runtime via metaClass, within the annotated scope, since static compilation assumes the code's structure is fixed and known at compile time.

@TypeChecked enables compile-time type checking on a class or method without necessarily forcing fully static method dispatch the way @CompileStatic does - it catches type errors earlier while Groovy can still use its normal dynamic dispatch at runtime.

It's a middle ground: you get earlier error detection than fully dynamic Groovy, without committing to all the dispatch-level changes and restrictions that come with @CompileStatic.

Because it only affects compile-time checking, not runtime dispatch behavior, it can be a lower-risk first step toward tightening a codebase's type safety before considering the more aggressive @CompileStatic.

A range represents a sequence of consecutive values, written with the .. operator, such as 1..10 for the integers 1 through 10 inclusive, or 'a'..'e' for a range of characters.

Ranges implement Groovy's List interface, so they can be iterated with each, used directly in a for loop, or converted into an actual list, without needing a separate range-specific API.

A common variant, 1..<10, is exclusive of the upper bound, letting you express "up to but not including" without manually subtracting one from the end value.

The Groovy Development Kit (GDK) refers to the extra methods Groovy adds onto existing Java classes - like String, Collection, and File - without modifying the JDK classes themselves, through Groovy's metaprogramming mechanisms.

For example, standard Java's List doesn't have an each method, but thanks to the GDK, any Java List used from Groovy code gains each, collect, find, and many other convenience methods automatically.

This means Groovy code working with plain Java objects from any Java library still gets access to Groovy's more expressive collection and string methods, without those Java classes ever being rewritten.

Grape is Groovy's built-in dependency management system, letting a Groovy script declare a Maven dependency inline with the @Grab annotation and have it downloaded and added to the classpath automatically when the script runs.

For example, annotating a script with @Grab('org.some:library:1.0') fetches that library and its transitive dependencies from a configured Maven repository the first time the script runs, caching it locally for subsequent runs.

This is particularly convenient for standalone scripts and quick prototyping, where setting up a full build tool just to pull in one library would be unnecessary overhead.

MarkupBuilder is a Groovy class that lets you generate XML (or HTML) output using ordinary Groovy method-call syntax instead of manually assembling and escaping markup strings by hand.

Each nested method call in the builder's closure corresponds to a nested tag - for example, calling books { book(title: 'Groovy in Action') } inside a MarkupBuilder produces the equivalent nested XML elements with the given attributes.

It's a concrete example of Groovy's builder pattern support, made possible by the language's flexible method-call and closure syntax rather than requiring a separate templating engine.

A trait is Groovy's mechanism for defining reusable, composable units of behavior - similar to a Java interface, but able to include actual method implementations and even state, not just method signatures.

A class can implement multiple traits, effectively mixing in behavior from each, which gives some of the benefits of multiple inheritance without the full complexity and ambiguity that traditional multiple class inheritance can introduce.

Traits predate Java's default interface methods (introduced later in Java 8) and go further, since Groovy traits can also carry actual fields/state, not just method bodies.

The with method lets you execute a block of code against a specific object without repeating that object's name for every call inside the block - calling person.with { name = 'Alice'; age = 30 } sets both properties on person without prefixing each line with person..

Inside the closure passed to with, unqualified property and method references resolve against the object with was called on automatically, since that object becomes the closure's delegate for the duration of the call.

It's commonly used to make a sequence of configuration calls on the same object more concise and readable, especially when constructing or configuring an object right after creating it.

Groovy makes semicolons, parentheses around method arguments (in many cases), and explicit return statements optional, so code can often be written more tersely than the equivalent Java without changing its meaning.

Groovy provides native syntax for lists and maps (like [1, 2, 3] and [key: 'value']) and adds operators Java lacks, such as the safe navigation operator ?., the Elvis operator ?:, and the spread operator *..

Typing is optional via def, == compares by value/equals rather than reference by default, and every class/method is public by default unless stated otherwise, all differing from Java's stricter, more verbose defaults.

The simplest way is the groovy command-line tool: groovy MyScript.groovy compiles and executes the script directly in one step, without a separate manual compile-then-run cycle.

Groovy also ships an interactive shell (groovysh) for evaluating expressions line by line, and a graphical Groovy Console for writing and running snippets with immediate output, both useful for quick experimentation.

For integrating Groovy into a build, Gradle - which uses Groovy or Kotlin as its own scripting language - or adding the Groovy JAR to a Java project's classpath lets Groovy scripts and classes run alongside compiled Java code in the same application.

In Groovy, == is overloaded to call .equals(), rather than performing raw reference/identity comparison the way Java's == does for objects, with null handled safely on either side.

To explicitly compare object identity, the same reference, in Groovy, you use the is() method, like a.is(b), since == no longer serves that purpose the way it does in Java.

This is a common source of confusion for developers coming from Java, where == on objects checks identity by default and .equals() has to be called explicitly for value comparison - Groovy essentially flips which operator does which by default.

Groovy lets you declare variables, parameters, and return types either explicitly (String name) or dynamically with def, mixing both styles freely within the same codebase or even the same method.

Without an explicit type or def-driven static checking, Groovy resolves method calls dynamically at runtime based on the object's actual type at that moment, rather than checking against a declared type at compile time.

Annotations like @TypeChecked and @CompileStatic let you opt specific classes or methods into stricter, Java-like compile-time type checking, so optional typing isn't all-or-nothing across an entire codebase - it can be applied selectively where it adds the most value.

def is convenient when a variable's type is either genuinely dynamic - it might hold different types over its life, like results from varied dynamic queries - or simply not important to state explicitly for a short-lived, informal script.

It reduces verbosity in scripting contexts, like a build script or a quick data-munging task, where declaring precise types on every local variable would add ceremony without much corresponding benefit to code that's read once and modified quickly.

In larger, long-lived application code, explicit types are generally preferred over def, since they improve IDE tooling support, make method signatures self-documenting, and let compile-time type checking actually catch mistakes - reaching for def everywhere isn't considered good practice outside genuinely dynamic or throwaway-script use cases.

A Groovy closure is a full object with its own identity, delegation strategy, and ability to be reassigned or reconfigured at runtime, like changing its delegate, while a Java lambda is a simpler, more restricted implementation of a single functional interface with no equivalent delegation concept.

Closures can access and modify effectively any variable from their enclosing scope, including reassigning it, whereas Java lambdas can only reference effectively final local variables from their enclosing scope and cannot reassign them.

Closures also carry runtime-introspectable properties like maximumNumberOfParameters and can be curried or memoized directly as built-in closure methods, capabilities a plain Java lambda doesn't expose without extra library support.

Every object in Groovy has an associated metaClass, which is the object responsible for actually resolving method calls and property access at runtime - it's the layer Groovy's dynamic dispatch goes through instead of directly hitting a fixed compiled vtable the way Java does.

Because the metaClass is itself modifiable at runtime, you can add a brand-new method to an existing class, even one you don't own, like String, by assigning a closure to that class's metaClass, and every instance of that class gains the new method afterward.

This is a powerful but double-edged capability: it enables things like custom DSLs and testing utilities that patch behavior temporarily, but overusing it in production code can make behavior harder to reason about, since a method's implementation isn't fixed purely by its declared class anymore.

Use @CompileStatic on performance-sensitive code paths - tight loops, hot methods called frequently - where the overhead of Groovy's dynamic method dispatch actually shows up as a measurable bottleneck, since static compilation resolves calls directly like Java does.

It's also worth applying where you want stronger compile-time guarantees on a class's correctness, such as a well-defined library API, and don't need runtime metaprogramming flexibility, like adding methods via metaClass, within that scope.

Avoid it on code that intentionally relies on Groovy's dynamic features - DSL-style code using methodMissing, dynamic metaClass modification, or duck-typing across unrelated classes - since @CompileStatic will reject or fail to resolve calls that depend on that dynamic behavior at compile time.

with executes a closure against an object and returns whatever the closure's last expression evaluates to - useful when you want the closure's own result back, not necessarily the original object.

tap also executes a closure against an object, using the same implicit delegation, but always returns the original object itself afterward, regardless of what the closure's body evaluates to - making it well suited for chaining, like configuring an object and then immediately using the same reference in a fluent call chain.

In short: use with when you want the closure's result, and tap when you want to keep chaining with the original object after running some side-effecting configuration on it.

Groovy maps standard operators onto specific method names that a class can implement - for example, defining a plus(other) method on a class lets instances of it be combined with the + operator, and Groovy automatically routes a + b to a.plus(b).

This covers most common operators, minus for -, multiply for *, and so on for comparisons and other operators too, so any class can participate naturally in Groovy's operator syntax just by implementing the corresponding method, without any special operator-specific syntax to learn.

Because it's just ordinary method dispatch under a conventional name, operator overloading in Groovy follows the same dynamic, or static under @CompileStatic, dispatch rules as any other method call - there's no separate operator-specific mechanism layered on top.

Most valid Java syntax is also valid Groovy syntax, with some narrow historical exceptions, meaning a .java file's contents can typically be renamed to .groovy and compiled/run as Groovy with the same behavior, without rewriting it.

On top of that Java-compatible base, Groovy layers additional syntax Java doesn't have - closures, native list/map literals, GStrings, the safe navigation and Elvis operators - purely as additions, not as replacements for existing Java constructs.

This design choice specifically lowers the adoption barrier for Java teams: they can write Groovy in a very Java-like style at first and gradually adopt more Groovy-specific idioms over time, rather than needing to learn an entirely different language upfront.

methodMissing is a special method you can implement on a class that Groovy's dynamic dispatch calls automatically when code invokes a method that doesn't actually exist on that object - instead of immediately throwing a MissingMethodException, Groovy gives the class a chance to handle the call itself.

Inside methodMissing, you receive the attempted method's name and its arguments, and can implement any custom logic - like dynamically generating a result, delegating to another object, or logging the unknown call - before returning a value as if the method had really existed.

This is a common technique for building expressive DSLs and proxy-like objects, where the exact set of "methods" that can be called isn't fixed in advance but is instead computed or interpreted dynamically based on the method name itself.

Groovy supports destructuring a list directly into several variables in one statement, like def (a, b, c) = [1, 2, 3], assigning each list element to the corresponding variable by position in a single line.

If the list has fewer elements than variables, the extra variables are simply assigned null rather than throwing an error, and if it has more elements, the extras are just ignored - the assignment doesn't require an exact length match.

This is commonly used with methods that return multiple values as a list, letting the caller unpack that list directly into named variables instead of manually indexing into a returned list afterward.

A Groovy script is a sequence of statements in a .groovy file that Groovy implicitly wraps in a generated class, extending groovy.lang.Script, at compile time, letting you write top-level executable code without explicitly declaring a class or a main method yourself.

A Groovy class, written explicitly with the class keyword, behaves like a normal class - instantiable, with its own methods and fields - and doesn't get this implicit script-wrapping behavior; it needs to be instantiated and used like any Java class would be.

Because a script is really just sugar over a generated class, you can freely mix top-level script statements with explicit class definitions in the same file, and the script's own code effectively becomes that generated class's run() method under the hood.

Use @Builder when a class's construction logic is straightforward - just setting a set of properties fluently - and you want the builder boilerplate, a separate builder class with chained setter-like methods and a build() method, generated automatically rather than hand-written and maintained.

Write a manual builder pattern instead when construction needs custom validation logic, conditional steps, or a build process that doesn't map cleanly onto @Builder's generated, mostly one-property-per-method structure.

@Builder also supports several strategies, like the default builder or one working well with @Immutable, so it's worth checking whether one of its built-in strategies actually fits the specific construction pattern needed before deciding a fully manual builder is necessary.

Groovy's switch can match against many more types of cases than Java's traditional switch, including regular expressions, ranges, classes (checking if the value is an instance of that class), and closures (checking if calling the closure with the value returns true), not just constants like Java's original switch.

Case matching in Groovy's switch uses the isCase method under the hood, and different types implement isCase differently - a Pattern's isCase does a regex match, a Class's isCase does an instanceof check - so the switch statement's flexibility comes from that same operator-overloading-style mechanism used elsewhere in Groovy.

Like Java's, Groovy's classic switch still requires explicit break statements to avoid fallthrough between cases, though modern Groovy versions have also added Java-like switch expressions with arrow syntax that avoid fallthrough entirely.

owner refers to the enclosing object where the closure was lexically defined - typically the surrounding class instance or another enclosing closure - and this never changes once the closure is created.

delegate is a separate, reassignable reference that Groovy also consults when resolving unqualified method/property calls inside the closure, and unlike owner, it can be explicitly changed at runtime, for example by a builder framework redirecting a closure's calls to a different target object.

Which one actually gets used to resolve a given unqualified call inside the closure depends on the closure's resolveStrategy, like OWNER_FIRST or DELEGATE_FIRST, which controls whether Groovy checks owner or delegate first when both could potentially resolve the same name.

Groovy's syntax allows optional parentheses, closures as trailing arguments, and native map/list literals, which together let a Groovy DSL read almost like a purpose-built configuration language, such as dependencies { implementation 'lib:1.0' }, while still being ordinary, fully-featured Groovy method calls under the hood.

Because it compiles to and runs on the JVM, a Groovy-based DSL like Gradle's build scripts can call directly into the full Java ecosystem - any existing Java library or plugin - without needing a separate interop layer, unlike a DSL built in a non-JVM language would.

This combination - syntax flexible enough to feel like a dedicated configuration language, while still being a real, Turing-complete programming language with full JVM interop - is specifically what makes Groovy well suited for build and pipeline DSLs where users need both simple declarative configuration and, occasionally, real conditional logic or scripting.

Groovy methods can declare default values for parameters directly in the method signature, like def greet(String name, String greeting = 'Hello'), letting callers omit the greeting argument and have it default automatically without needing multiple overloaded method signatures.

True named-parameter method calls, using name: value syntax at the call site, work specifically through a map-based convention: a method accepting a single Map argument as its first parameter can be called with that map expressed as name: value pairs, giving the appearance of named arguments even though it's really passing one Map object.

Together, these features let Groovy APIs, and constructors, which support the same map-based named-argument convention for setting properties, read more like readable, self-documenting calls than Java's purely positional argument lists.

@Immutable is an AST transformation that automatically generates an immutable class from a simple property declaration list - final fields, a suitable constructor, equals/hashCode/toString, and defensive copying for mutable-looking property types like collections - all without writing that boilerplate by hand.

A manually written immutable class requires writing all of that yourself: declaring every field final, writing a constructor that assigns them, implementing equals/hashCode/toString consistently, and remembering to defensively copy any mutable-looking fields on the way in and out, each of which is an easy place to introduce a subtle bug if done manually and inconsistently.

The tradeoff is customization: @Immutable's generated behavior follows fixed conventions, so a class needing unusual construction logic, non-standard equality semantics, or special handling not covered by its defaults may still need to be hand-written instead.

Groovy's compiler processes source code through several sequential phases - initialization, parsing, and building an initial Abstract Syntax Tree (AST) that represents the program's structure before any transformation-specific work happens.

Local AST transformations, triggered by an annotation like @ToString placed directly on a class, are registered to run at a specific compilation phase, commonly CANONICALIZATION, and are invoked by the compiler once the AST reaches that phase, receiving a reference to the relevant AST node - the annotated class - to modify.

The transformation implementation directly manipulates the AST - for example, @ToString's transformation adds a new MethodNode representing a generated toString() method into the class's AST - as ordinary tree edits, not as source-code string generation.

Because this happens before bytecode generation, the modified AST, including the newly added method, is what the compiler actually turns into bytecode in the subsequent code-generation phase, so the generated method behaves identically to one that had been hand-written in the original source.

Global AST transformations, not tied to a specific annotation, are also possible, registered via a service-provider file so they run automatically on every compilation unit the compiler processes, useful for org-wide compiler-level policies rather than per-class opt-in behavior.

flowchart LR
  A[Source code] --> B[Parse to initial AST]
  B --> C{Annotation triggers local AST transformation?}
  C -- Yes --> D[Transformation edits AST: adds/modifies nodes]
  C -- No --> E[AST unchanged]
  D --> F[Bytecode generation from final AST]
  E --> F

Apply @CompileStatic to hot, frequently-executed code paths first - tight loops, methods called in high volume - since that's where the overhead of Groovy's dynamic dispatch, looking up the right method implementation through the metaClass on every call, actually accumulates into a measurable cost.

Where full @CompileStatic isn't practical because some dynamic behavior is genuinely needed, apply @CompileStatic at a finer granularity, on specific methods rather than an entire class, so only the performance-critical parts pay the restriction cost while the rest of the class keeps its dynamic flexibility.

Combine static compilation with avoiding unnecessary GString usage and closure allocation inside hot loops, since both carry their own overhead - GString evaluation, closure object creation - independent of dispatch style, and neither is automatically eliminated just by adding @CompileStatic.

Profile before and after applying static compilation rather than assuming it will help uniformly - some genuinely dynamic patterns, like heavy metaClass-based DSL usage, don't benefit and may even need to stay dynamic, so static compilation is a targeted optimization, not a blanket setting to apply everywhere.

Read the exception message carefully first - it names the exact method signature Groovy tried and failed to resolve, method name plus argument types, which is usually enough to spot a typo, wrong argument count, or wrong argument type at the call site.

Check whether the target object's actual runtime type is what you expected - Groovy's dynamic dispatch resolves based on the object's real type at the moment of the call, so a variable declared with def holding an unexpected type, from an earlier reassignment or an unexpected return value from another method, is a common cause that a purely static read-through of the code might miss.

If the method is supposed to be dynamically supplied - via metaClass, a mixin, a Category, or a methodMissing implementation - verify that mechanism is actually active in the current context; a Category applied inside a use {} block, for example, only affects code within that block's scope, not the whole application, and calling the same method outside that block will fail to resolve.

If @CompileStatic or @TypeChecked is applied to the calling code, remember these enforce compile-time resolution against a known, static type - a call that would have worked dynamically may now fail to even compile, and the fix is either providing an explicit type hint, or reconsidering whether that method call belongs in statically-compiled code at all.

Every Groovy object delegates method calls and property access through an associated MetaClass, obtained from the MetaClassRegistry - rather than the JVM dispatching directly to a fixed compiled method table the way plain Java bytecode does, Groovy inserts this MetaClass lookup as an extra layer at or near every call site.

When a method is invoked dynamically, the MetaClass first checks whether the method exists as a normally declared method on the class or its GDK extensions; if found, it dispatches there, and if not found, it falls through Groovy's defined fallback chain - checking for a methodMissing implementation, then ultimately throwing a MissingMethodException if nothing resolves the call.

Because the MetaClass itself is a regular, inspectable and modifiable object, code can retrieve an object's or class's metaClass at runtime and register new methods, override existing ones, or intercept every call via invokeMethod - this is the mechanism underlying Groovy Categories, mixins, and dynamic method injection.

@CompileStatic effectively bypasses most of this machinery for annotated code: instead of going through the MetaClass at runtime, the compiler resolves method calls directly against known types at compile time and emits direct invocation bytecode, which is precisely why statically compiled code can't participate in metaClass-based dynamic patching within that same scope.

This layered lookup - real method, then GDK extension, then metaClass customization, then methodMissing, then failure - is what gives Groovy both its dynamic flexibility and a well-defined, predictable order for where a given call's behavior actually comes from when several of these could theoretically apply.

flowchart TD
  A[Method call on object] --> B[Consult object's MetaClass]
  B --> C{Declared method or GDK extension exists?}
  C -- Yes --> D[Dispatch to that method]
  C -- No --> E{metaClass customization registered?}
  E -- Yes --> D
  E -- No --> F{methodMissing implemented?}
  F -- Yes --> D
  F -- No --> G[Throw MissingMethodException]

When a closure is created, it captures references relevant to call resolution: this, the enclosing class instance where the closure syntax appears; owner, typically the same as this unless the closure is nested inside another closure, in which case owner is the enclosing closure; and delegate, initially the same as owner but explicitly reassignable afterward.

When the closure body references an unqualified name, a method call or property with no explicit target, Groovy resolves it by consulting owner and delegate in an order determined by the closure's resolveStrategy - OWNER_FIRST, the default, checks owner first and falls back to delegate only if owner doesn't resolve it, while DELEGATE_FIRST reverses that order.

Frameworks that build DSLs, like Gradle's configuration blocks, commonly reassign a closure's delegate to a builder or configuration object and set resolveStrategy to DELEGATE_FIRST, so that unqualified calls inside a user's configuration block resolve against that builder object instead of the surrounding class where the block happens to be written - this is exactly the mechanism that makes DSL-style nested configuration blocks work.

Two further strategies, OWNER_ONLY and DELEGATE_ONLY, skip the fallback step entirely and only ever consult one of the two, useful when a framework needs to guarantee calls resolve exclusively against the delegate, or exclusively against owner, with no possibility of accidentally falling through to the other.

A closure's memoize() method wraps it in a caching layer that stores the result of each unique set of input arguments the first time it's computed, so subsequent calls with the same arguments return the cached result instead of recomputing it - useful for expensive, pure computations called repeatedly with a limited set of distinct inputs.

Because the cache is keyed on the exact argument values, memoization only helps when calls genuinely repeat with the same inputs; applying it to a closure whose arguments are essentially always unique adds caching overhead with little or no benefit, since nothing is ever actually reused from the cache.

Groovy also provides memoizeAtMost and memoizeAtLeast variants that bound the cache's size, which matters for long-running processes where an unbounded cache built from unbounded distinct inputs would otherwise grow indefinitely and become its own memory problem.

Memoization is best applied to genuinely pure functions - if the closure has side effects or depends on external mutable state beyond its arguments, caching by argument value alone can silently return a stale or simply wrong result on a later call where that external state has since changed.

This isn't strictly either-or in practice - Groovy's own built-in builders, like MarkupBuilder, are themselves implemented using closures under the hood, so the more useful framing is which layer of abstraction to expose to the DSL's actual end users.

Raw closures with delegate reassignment give maximum flexibility with the least code to write upfront - fine for a simple, internal DSL where the audience is other developers comfortable reading Groovy closure syntax directly and the structure being configured is relatively simple and stable.

A dedicated builder class, potentially still implemented internally using closures and delegation, is worth the extra upfront work when the DSL needs a more constrained, discoverable API - IDE autocompletion working well, clear validation errors, and a documented set of exactly what's configurable - which matters more as the DSL's audience grows beyond the original author or the structure becomes more complex.

In short: reach for closures directly for something quick, internal, and structurally simple; invest in a purpose-built builder class when the DSL will be used broadly, needs strong tooling support, or benefits from validating its structure rather than accepting arbitrary closure content.

Groovy's collection literals and GDK methods operate on standard Java collection types under the hood, so the same rule applies as in plain Java: modifying a collection, adding or removing elements, while iterating over it directly with each, for, or an iterator will throw this exception, since the underlying iterator detects the structural change mid-iteration.

A common, Groovy-specific trap is doing this inside a closure passed to each or findAll - it's easy to overlook that the closure is iterating live over the original collection, especially when the modifying call is buried a few lines into the closure body rather than obviously adjacent to the iteration itself.

The fix is usually to iterate over a copy, like list.toList() or a new ArrayList(list), when modification during iteration is needed, or better, to use a transformation method that returns a new collection instead of mutating in place - using collect or findAll to build a new filtered/transformed list rather than removing elements from the original while iterating it.

If genuinely concurrent, multi-threaded, modification is the actual cause rather than same-thread iteration-plus-mutation, a thread-safe collection type or explicit synchronization is needed instead - iterating over a copy alone doesn't fix a true multi-threaded race, since another thread could still be mutating the original list at the same time.

A Category is an ordinary Groovy or Java class containing static methods, each written with the "extended" type as the first parameter - for example a static method String reversed(String self) defines a reversed() method that appears to be added onto String, but only within a specific scope, not permanently.

Calling use(SomeCategory) { ... } temporarily registers that Category's static methods onto the metaClass lookup chain for the duration of the closure passed to use, scoped specifically to the current thread executing that block - it doesn't globally or permanently modify the target classes' metaClass the way a direct metaClass assignment would.

Inside that closure, any call matching one of the Category's method signatures by first-parameter type resolves to the Category's static method, with self bound to the actual receiver object the method was called on - to code inside the block, it looks exactly like an ordinary instance method call.

Once the use block's closure finishes executing, the Category's methods are automatically deregistered from the lookup chain - calling the same method again outside the block, even on the same object, fails to resolve, since the temporary registration was scoped strictly to that block's execution.

This makes Categories well suited to safely and temporarily extending even classes you don't own, like adding a method to String, for a specific, bounded piece of code, without risking that extension leaking out and unexpectedly changing behavior elsewhere in the application.

flowchart LR
  A[use SomeCategory closure] --> B[Register Category's static methods on lookup chain]
  B --> C[Calls inside block resolve to Category methods]
  C --> D[Block finishes executing]
  D --> E[Category methods automatically deregistered]

Rather than applying @CompileStatic to an entire large script or class wholesale, which can force rewriting genuinely dynamic sections just to make them compile, apply it selectively at the method level, keeping only the performance-critical or type-stable methods statically compiled while leaving genuinely dynamic methods, DSL-handling code, metaClass-based logic, without the annotation.

Use @CompileDynamic on specific methods within an otherwise @CompileStatic-annotated class as an explicit escape hatch - this lets you default a class to static compilation for most of its methods while carving out one or two methods that need to stay dynamic, without needing to remove @CompileStatic from the whole class.

Structure the script so dynamic, DSL-style configuration code, which benefits from Groovy's flexibility, is separated from data-processing or computational logic, which benefits from static compilation's performance, rather than interleaving both styles throughout the same method - this makes the mixed-compilation boundaries clean and easy to reason about instead of scattered.

Measure actual impact before committing to this restructuring effort broadly across a large script - the dispatch overhead @CompileStatic removes is most significant in tight loops and high-call-volume paths; applying it to code that runs rarely, like one-time startup configuration, won't meaningfully change overall performance and just adds restriction for no measurable gain.

Currying, via a closure's curry() method, produces a new closure with one or more of the original closure's leading parameters pre-filled with fixed values, reducing the number of arguments the resulting closure still expects when it's eventually called.

Internally, calling curry(value) doesn't invoke the original closure immediately - it wraps the original closure in a new curried closure object that remembers the supplied value(s) and the original closure reference, deferring actual execution until the curried closure itself is finally called with its remaining arguments.

When the curried closure is eventually invoked with the rest of the arguments, it combines the previously curried, fixed, values with the newly supplied ones, in the correct parameter order, and only then delegates to the original closure's actual body with the complete, combined argument list.

Groovy also supports rcurry(), which curries from the right/trailing parameters instead of the left/leading ones, and ncurry(), which curries starting at a specific parameter index, giving flexibility in which parameters get pre-filled rather than always being restricted to the leftmost ones.

This is commonly used to specialize a general-purpose closure into a more specific one - for example, currying a generic add(a, b) closure with a fixed first value produces a reusable "add5" closure - without writing a separate, explicitly named closure for each specialized variant.

flowchart LR
  A[Original closure: add a,b] --> B[Call curry 5]
  B --> C[New curried closure: remembers value 5]
  C --> D[Later call: curried closure with b]
  D --> E[Combine 5 and b, delegate to original closure body]

Start by identifying the actual runtime type and value of the expression being evaluated in the conditional - Groovy Truth rules differ meaningfully by type, empty String, empty Collection, and zero-valued Number are all falsy, but a non-null object with no special truthiness rule defined is simply true regardless of its internal state, so "why is this true or false" often comes down to which type-specific rule actually applied.

A frequent surprise is a custom object being unexpectedly treated as true even when it seems "empty" in some domain sense - unless that class implements asBoolean() to define custom truthiness, Groovy Truth for arbitrary objects defaults to true whenever the reference is simply non-null, regardless of the object's internal state.

To fix genuinely unexpected behavior, either implement asBoolean() on the class to define what "truthy" specifically means for it, or make the conditional's intent explicit by checking the specific condition directly, like list.isEmpty() or someValue != null, instead of relying on the implicit Groovy Truth conversion, especially in code where the exact falsy/truthy rule matters and shouldn't be left implicit.

When debugging, it also helps to explicitly convert the value to a boolean in isolation to directly observe what Groovy Truth resolves it to, rather than inferring it indirectly from the conditional's overall behavior in a larger, more complex expression.