The platform's server-side scripting layer now supports Apache Groovy as a third engine. Where JavaScript runs on GraalVM and Python runs as a GraalVM guest language, Groovy runs JVM-native through the JSR-223 script engine API — no GraalVM required. The Ax standard library is fully available, so existing library patterns transfer without rewriting.
Engine behaviour
- Opt-in per deployment. Groovy execution is gated by a server flag; if the flag is off, a
<script type='groovy'>block is rejected at parse time so the engine cannot be reached accidentally. - Full standard library parity. Singleton modules —
Ax.math,Ax.db, result sets, context — are accessible through Groovy's native map-property semantics. The same library patterns developers use in JavaScript scripts work in Groovy without rewriting. - JVM-native interop. Groovy can call Java classes directly. Teams that already have utility code on the JVM can invoke it without marshalling through a polyglot boundary.
- Cancellation support. Long-running scripts respond to server-side interrupt signals, consistent with how Python and JavaScript scripts behave under load control.
When to choose Groovy
- Java shops. Teams fluent in the Java ecosystem get a familiar syntax and zero-friction access to existing JVM libraries.
- No GraalVM overhead. For deployments that want an additional scripting option without the GraalVM runtime footprint, Groovy is a lighter alternative to the polyglot engines.
JavaScript remains the default scripting language; Python and Groovy are both opt-in. All three engines share the Ax runtime and the same cancellation and permission model.