CompileStatic Configuration for Low‑Traffic Groovy Workloads

Answer

Yes – @CompileStatic should be applied only to Groovy classes that can be proven free of dynamic metaprogramming (methodMissing, propertyMissing, categories, Expando). Package‑level annotation is not enough; per‑class (or per‑method) granularity is required to keep dynamic escape hatches where they are needed.

Confirmed facts

• @CompileStatic is an AST transformation that generates Java bytecode with static type checking, eliminating Groovy’s meta‑class dispatch.
• For low‑traffic workloads the CPU savings are usually modest; the main gain comes from reduced startup and per‑request latency.
• Any class annotated with @CompileStatic cannot use dynamic features; attempting to do so yields a compilation error or runtime NoSuchMethodError.

Steps for this case

1. Identify candidate classes: POJOs, utility or service classes that use explicit typing and do not reference def, methodMissing, propertyMissing, categories, or ExpandoMetaClass.
2. Add @groovy.transform.CompileStatic to the class header (or to specific methods if only part of the class needs static compilation).
3. Recompile the project; the build will fail if any incompatible dynamic construct is present.
4. Run the full test suite to catch any hidden dynamic calls that survived compilation.

Analysis and verification

To automate candidate selection, run a static inspection that flags:

• Variable or parameter types declared as def or Object without casting.
• Calls to methodMissing, propertyMissing, or use of GroovyCategories.
• References to ExpandoMetaClass.

Many IDEs (IntelliJ IDEA, Eclipse Groovy) provide inspections for dynamic call or unsafe type. A simple Gradle task can run the Groovy compiler with -XstaticCompile to report incompatibilities.

Measure the impact with a scoped benchmark, for example:

long start = System.nanoTime();
service.handleRequest();
long end = System.nanoTime();
println 'Request time: ' + (end - start) + ' ns';

Missing diagnostic detail: Does the codebase use Groovy Categories or ExpandoMetaClass for cross‑cutting concerns? If yes, those specific classes must remain dynamic, as static compilation will ignore those runtime extensions.