Embedding a scripting/macro system in small apps (desktop tools, internal apps, self-hosted servers) no longer has the option of the JVM Security Manager, which JEP 486 disabled in JDK 24. Rather than reaching for containers, microVMs, GraalVM isolates, or WebAssembly (all of which add distribution and operational burden unsuited to small teams), the author argues for a lightweight, embeddable interpreter with a minimal, explicit allowlist-based security model. Using Aussom, an Apache 2.0 JVM interpreter the author maintains, as the example, the post shows benchmark numbers (2.6ms engine creation, 0.37MB per idle engine, 20,000 engines in one JVM) and a six-line code sample for evaluating user-typed expressions safely, plus instant cancellation of runaway scripts.
Table of contents
The usual options, and why they don't fitWhat small apps actually need: simplicityWhat you getHello worldWhere this leaves youQuestions this post answers
Why can't I use the Java Security Manager to sandbox scripts anymore in JDK 24?
JEP 486 disabled the Security Manager in JDK 24 and it cannot be turned back on, per OpenJDK's own statement that the platform no longer has a sandbox. This removes the approach many JVM apps used for twenty years to safely embed Groovy or JavaScript engines, forcing developers who need scripting or macro features to find alternative isolation strategies. daily.dev tracks JDK platform changes like this so you're not caught off guard when a security mechanism disappears.
How much memory and time does it take to create a scripting engine instance with Aussom?
An Aussom engine costs about 2.6 milliseconds to create once the JVM is warm and holds 0.37 MB while idle. Twenty thousand engines fit in a single JVM using 7.5 GB total, built in 29 seconds, with the per-engine memory cost staying flat from ten engines up to twenty thousand. Developers evaluating embeddable scripting engines can weigh benchmarks like these on daily.dev before choosing an approach.
What are the alternatives to containers or microVMs for sandboxing user scripts in a small desktop or self-hosted Java app?
Options include containers or microVMs, running scripts in a second process, GraalVM isolates, WebAssembly modules, or an embedded interpreter with an explicit allowlist security model. Containers require users to install Docker, a second process adds startup latency and IPC overhead, GraalVM isolates require a native-image build step and per-OS artifacts, and Wasm requires users to write Rust or embed another JS engine inside it. Comparing sandboxing trade-offs for small apps is easier when developers follow this kind of analysis on daily.dev.