I have just learned that Larry has been drinking the MAGA CooiAid! So don't expect any sanity from Oracle.
It might be better to create a Groovy GVM, and have an option to convert JVM binaries to GVM binaries on the fly at startup. The Groovy compile should recognize JVM code in libraries and automatically convert them to GVM binaries. So when running code you are completely in the Groovy world, but still have access to Java tools and libraries. This will isolate Groovy more from Larry Boy! Tommy Svensson [email protected] Från: Paolo Di Tommaso <[email protected]> Svara: [email protected] <[email protected]> Datum: 2 augusti 2026 at 15:01:29 Till: [email protected] <[email protected]> Ämne: Re: Groovy sandboxing Leaving an exhaustive reply to core maintainers however I believe that would require running Groovy on Truffle (Graal polyglot API). That would be cool, but I see no plan in that direction. Paolo On Sat, Aug 1, 2026 at 11:34 PM ski n < [email protected]> wrote: Groovy has always been a powerful scripting language. Now with agents (for example created with Spring AI or Langchain4j) it's becoming more common to run Groovy scripts from for example Java or Kotlin. The question is when third-party generated scripts from agents (or just a script written by other developers) run these scripts, how to run it safely and securely? For example by not giving it access to the file system, socket or environment. I recently read the documentation of GraalVM on sandboxing: https://www.graalvm.org/latest/security-guide/sandboxing/ There you can have guest code (JavaScript, Python, Wasm etc) that is a sandbox when started from the JVM/GraalVM. This works because guest languages run in a separate VM, truffle VM, where these restriction policies can be applied. Groovy as being a JVM language itself, runs natively on the JVM, and is very much integrated with other JVM languages such as Java. Historically there have been several approaches to run Groovy restrictly such as: SecureASTCustomizer custom classloaders SecurityManager (now removed from Java) bytecode rewriting custom compilation restrictions Unfortunately, after the removal of the Java Security Manager, there is no robust, built-in JVM mechanism for securely sandboxing arbitrary Groovy code. Are there any plans to allow strong sandboxing for Groovy embedded in another JVM Language? Raymond
