--- title: "Scripting in small apps: you don’t need a container for a macro" url: https://daily.dev/posts/scripting-in-small-apps-you-don-t-need-a-container-for-a-macro-qdx4d72pt source_url: https://foojay.io/today/scripting-in-small-apps-you-dont-need-a-container-for-a-macro type: article source: "Foojay.io" published: 2026-08-25T07:52:25.360Z updated: 2026-08-25T07:52:54.812Z tags: ["java", "jvm"] reading_time: 7 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Scripting in small apps: you don’t need a container for a macro **[Foojay.io](https://daily.dev/sources/foojayio)** · 7 min read · 1 upvotes · 0 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions 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._ ## Similar posts on daily.dev - [Sandboxing Script Extensions with GraalVM](https://daily.dev/posts/sandboxing-script-extensions-with-graalvm-yksnjrczv) · GraalVM Blog · 0 upvotes · 0 comments --- Tags: [#java](https://daily.dev/tags/java), [#jvm](https://daily.dev/tags/jvm) [View this post on daily.dev](https://daily.dev/posts/scripting-in-small-apps-you-don-t-need-a-container-for-a-macro-qdx4d72pt)