# Apache Groovy: a JVM language for scripting, DSLs and gradual static typing

> Apache Groovy is an Apache-2.0 language for the JVM that mixes dynamic scripting with optional static compilation and type checking. It fits teams that want Java interop without Java verbosity, and it is the wrong choice when you need a small runtime or a fully static toolchain.

**apache/groovy** — Apache Groovy: A powerful multi-faceted programming language for the JVM platform.

- Repository: https://github.com/apache/groovy
- Website: https://groovy-lang.org
- Stars: 5,471 · Forks: 1,915
- Language: Java
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/apache-groovy

## The problem Apache Groovy solves, and the developer it targets

Java gives you a large standard library, a mature toolchain and a runtime that is already installed almost everywhere. What it does not give you is a short path from an idea to a running script. A build file, a test fixture, a data migration one-liner or a small DSL for a configuration format all tend to grow boilerplate faster than they grow logic. Apache Groovy targets that gap. The README describes it as "a powerful multi-faceted programming language for the JVM platform" that supports "a spectrum of programming styles incorporating features from dynamic languages such as optional and duck typing, but also static compilation and static type checking at levels similar to or greater than Java through its extensible static type checker." The intended audience is therefore not someone choosing a first language. It is a JVM developer, or a build or platform engineer, who wants scripting ergonomics while keeping the Java class library, the JVM's threading model and existing Java dependencies within reach. The README also states that Groovy "integrates smoothly with any Java class or library", which is the practical claim that matters: your existing jars do not need wrappers. The language is also positioned for Domain-Specific Language authoring, runtime and compile-time meta-programming, and functional programming, so the target user is often writing a tool for other developers rather than an end-user application.

## How Groovy works: dynamic by default, static on request

Groovy is not an interpreter bolted onto the side of the JVM. It is a language whose code compiles to JVM bytecode, and the repository layout reflects that: the source tree contains a compiler and runtime, and the top level carries build-logic, subprojects and a compatibility directory alongside the usual Apache governance files. The design choice that separates Groovy from plain Java is that the same source file can be compiled with dynamic dispatch or with static compilation and static type checking. The README states that the static type checker is extensible and that static type checking operates at levels "similar to or greater than Java". That means the language does not force a single semantics on you: you can write a quick dynamic script and later annotate the hot or risky parts to get compile-time verification. The cost of that flexibility is that behaviour depends on which mode a given class or method is compiled under, so a method that works dynamically can fail a static compile, and a statically compiled method gives up some of the meta-programming tricks that dynamic Groovy permits. The README lists runtime and compile-time meta-programming as first-class capabilities, which is exactly the feature set that static compilation restricts. Treat that tension as the central architectural fact about Groovy rather than a footnote.

## Installing Groovy and running a first script

The README does not inline install commands. It points to the project's download page, stating that distribution links are on the download page, and notes that Maven, Gradle and Ivy dependency declaration snippets are available on specific files of a particular module. So the first step is to open that download page and pick a distribution. If you are consuming Groovy as a library inside an existing build, declare it as a dependency instead of installing a distribution at all. The README does not print the coordinates, so take them from the module files rather than from memory.

If you build Groovy from a source distribution rather than cloning the Git repository, the README says you must bootstrap Gradle first. The command it gives, run from the top directory of the unpacked source, is:

```bash
gradle -p bootstrap
```

The README then notes that after this step the Gradle wrapper is set up and you should use the `gradlew` command instead of `gradle`, with `./gradlew` on Unix-like systems. The repository ships both `gradlew` and `gradlew.bat`, so the wrapper is present for Windows as well. The build requires JDK 17 or later, and the README adds that the build compiles with whichever JDK runs `gradlew`; to target a different bytecode level or test on a different JDK it refers to the "Building and testing against a specific JDK" section of CONTRIBUTING.md. The full build command given in the README is:

```bash
gradlew cl
```

For a first real use, the lowest-risk path is to install a distribution from the download page and run a script file with the `groovy` launcher, rather than building the language from source. Building from source is for contributors and for people who need a patched compiler, and it costs you a Gradle bootstrap plus a full build before you can execute anything.

## Where Groovy is the wrong tool

The dynamic default is a genuine liability in some settings. If a method name is resolved at runtime, a typo becomes a runtime failure rather than a compile error, and the failure surfaces on the code path that exercises it. Groovy offers static compilation and static type checking to close that hole, but the README frames those as options within a spectrum, not as the baseline. A team that wants every call site checked by the compiler should either commit to statically compiling its Groovy or choose a language where that is the only mode. The second constraint is the platform. Groovy runs on the JVM, so it inherits JVM startup and memory characteristics, and it is a poor choice for a short-lived command-line utility where process start time dominates the work. The README does not make any claim about startup time, and no performance figure should be assumed from it. Third, the meta-programming and DSL features that make Groovy attractive for framework authors are the same features that make a codebase hard to read for someone who does not know which methods were added at runtime. If your team cannot afford to learn where those hooks live, the DSL will look like magic. Finally, the JDK requirement is a real gate: the README states JDK 17+ for building, and the compatibility directory and COMPATIBILITY.md at the repository root exist precisely because version and JDK pairings matter. Check that file before you assume a given Groovy release runs on the JDK your production image ships.

## Groovy next to Kotlin and JSR-223 scripting

The closest alternative for most JVM teams is Kotlin. The difference is in the default, not the feature list. Kotlin is statically typed as its normal mode and interops with Java classes directly. Groovy is dynamic as its normal mode and adds static checking as an opt-in through its extensible type checker. If your team's failure mode is runtime surprises, Kotlin's default catches them earlier. If your team's problem is expressing a configuration language, a build DSL or a test harness concisely, Groovy's dynamic mode and meta-programming are the reason to pick it, and Kotlin asks you to write more ceremony for the same result. A second alternative is to stay on the JVM without adopting a new language at all, using the platform's scripting support to run small scripts from inside Java. That keeps your toolchain unchanged and avoids a second compiler, but it gives you a scripting language without Groovy's static type checking, DSL authoring support or meta-programming, which is most of what the README advertises. The honest framing is that Groovy and Kotlin overlap heavily on Java interop and diverge on when type errors are reported, and that choice should be made from your team's tolerance for runtime failures rather than from a feature checklist.

## Maintenance, build cost and the Apache-2.0 licence

The repository is not archived and sits under the Apache Software Foundation, with the governance and contribution files you would expect at the top level: GOVERNANCE.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md and a DOAP.rdf descriptor. The README's revision date line reads 24-02-2014, which is the document's own date marker and not a statement about the code. The last push date was not available, so no claim about how recently the code changed can be made. The build cost is concrete and worth planning for. Building from a source distribution needs a Gradle bootstrap step before the wrapper is usable, and the build requires JDK 17 or later. The README also points at CONTRIBUTING.md for building and testing against a specific JDK, which signals that cross-JDK work is a supported but non-trivial path. On licensing, Groovy is released under Apache-2.0, and the README carries the standard Apache header and a NOTICE file is present at the repository root. Apache-2.0 is a permissive licence that permits commercial use and modification, but it also carries notice and attribution obligations, and the repository separates LICENSE from NOTICE for that reason. Whether those obligations fit a given product is a question for your own legal review, not something a README can settle.

## Conclusion

Adopt Apache Groovy when you already run a JVM and want shorter scripts, DSL authoring or optional static type checking without leaving the Java ecosystem. Do not adopt it if you need a minimal runtime footprint or a language whose semantics are fully static by default, since Groovy's dynamic mode and meta-programming are the point of the design rather than an accident. Before committing, verify the exact distribution link on the download page, confirm the JDK 17+ requirement against your build image, and read COMPATIBILITY.md for the version-to-JDK matrix your project must live inside.

## FAQ

### How do I install Apache Groovy?

The README does not list install commands. It states that distribution links are on the project's download page, and that Maven, Gradle and Ivy dependency snippets are available on specific files of a particular module, so use the download page for a standalone install or the module files for a build dependency.

### How do I install Apache Groovy on Windows?

The README points to the download page for distributions rather than giving platform-specific steps. The repository does ship gradlew.bat for Windows, but that is for building Groovy from source, which the README says requires JDK 17+ and a Gradle bootstrap step.

### How do I use Apache Groovy?

Groovy is a JVM language that compiles to bytecode and integrates with any Java class or library, according to the README. It supports dynamic features such as optional and duck typing as well as static compilation and static type checking, and the README lists scripting support, DSL authoring, meta-programming and functional programming among its capabilities.

## Sources

- [Official documentation](https://groovy-lang.org)
- [Official README](https://github.com/apache/groovy#readme)
- [Project repository](https://github.com/apache/groovy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-groovy