Why Aussom?

Austin Lehman — Sat, 18 Jul 2026 03:02:50 +0000

You have a Java application, and now you need it to do something Java is awkward at. Maybe you want to let users script your app without recompiling it. Maybe you want to change a piece of business logic without a full redeploy. Maybe you just want to run a quick, throwaway script and not stand up a whole build. Java is a phenomenal language and runtime, but these are the edges where it starts to feel heavy. That is exactly the space Aussom is built for.

I started using Java almost 20 years ago and have loved every bit of it. I'm proud of all the recent momentum in the Java space and I hope it continues. Java does so much so well. But every great tool has an edge where it stops being the right one, and reaching for another language there isn't a betrayal of Java. It's how the best ecosystems work.

A useful comparison: C and Python

Look at C. C is clearly important. Even after a lifetime of use it's still the foundation for new projects today, and new competitors such as Rust haven't been able to meaningfully displace it. C is fast and powerful on its own, but it isn't great for simple tasks. It's poor for throwaway code and quick scripts, it isn't very portable, and it hands you plenty of footguns. It's also a poor choice when you want to offer a scripting interface.

Enter Python. Python is everywhere today because the barrier to entry is so low and it's genuinely useful. But Python leans on C. It's written in C, and much of its power comes from existing C libraries, whether they're UI frameworks, AI inference engines, or anything in between. C is efficient but poor at simple dynamic work; Python is dynamic and simple but poor at raw power and efficiency. Neither replaced the other. They endure together because they complement each other's weaknesses.

That is the case I make for Aussom. Aussom is to Java as Python is to C. It doesn't compete with Java, it complements it.

What makes Aussom different from other JVM languages

This is where Aussom parts ways with most of its neighbors. Kotlin, Scala, Groovy, Clojure, and friends compile to JVM bytecode. However different their syntax, they ultimately produce bytecode that's handed to the JVM to run, so they live inside the JVM's rules.

Aussom does not compile to bytecode. The Aussom runtime is compiled and starts up on the JVM, but your Aussom program is never compiled. The runtime parses it on the fly and interprets it directly. There's no compile step, and the JVM's rules don't apply to your code. Because a program is just text until the moment it runs, Aussom can load and unload code at runtime, in real time.

For a Java developer, that means you can hand Aussom a string, run it, throw it away, and hand it another one, all inside a running JVM process.

What it looks like

For quick work, an Aussom script is just a .auss file of top-level statements. No class, no main, no ceremony. Read some input, print some output, and you're done:

include os;

name = os.readLine("Your name: ");
os.printf("Hello, {}!\n", name);

// Uppercase whatever is piped in: echo hi | ./shout.auss
text = os.readAll();
os.out(text.toUpper());

The language will still feel familiar. Lists and maps have first-class literals, try/catch works the way you'd expect, and the standard library covers the everyday scripting jobs:

include os;
include http;

res = new Http().get("https://api.example.com/status");
if (!res.info.isSuccessful) {
    os.outErr("request failed: " + res.info.responseCode);
    os.exit(1);
}

data = json.parse(res.body);
os.printf("state: {}\n", data.get("state"));

When a script grows up into something bigger, the same language scales into classes, methods, and modules, so nothing you learn in script mode is thrown away.

Embedding it in your Java app

Here's the part that matters most for a Java shop. You embed the interpreter directly:

Engine eng = new Engine(new SecurityManagerImpl());
eng.parseFile("script.aus");
int result = eng.run();

That's the whole integration. The script is data, so it can come from a file, a database row, a text field in your admin UI, or a request body. You decide where the code lives and when it runs.

The security model

Letting arbitrary code run inside your process should make you nervous, and that's precisely why Aussom is built around a security manager. The Engine takes a SecurityManagerInt, and sensitive actions are gated by named properties such as reflect.eval.string (run code built at runtime), current.path.view (see the working directory), or os.info.view (read details about the host). The built-in SecurityManagerImpl denies these by default, so you opt in to exactly what you're comfortable granting, and you can supply your own implementation for finer control. That makes Aussom a real option for a user-facing scripting interface, not just internal glue.

Why not just use X?

A fair question. JShell and scripting engines such as Nashorn or GraalVM's JavaScript can evaluate code at runtime too, and Groovy has long been the go-to for JVM scripting. Aussom's distinction is the combination: pure interpretation with no compile step, true load-and-unload of code at runtime, a small and familiar syntax, and a built-in, property-based security model designed for handing scripting to your users. It's aiming to be the simple, dynamic complement to Java, not another way to write Java.

Try it

Java isn't bad at these tasks; it's just built for something else. When you need something simple, dynamic, and safely embeddable, that's where Aussom shines.

The easiest way to get a feel for it is the online playground. No install, no setup, just write a script and run it right in your browser:

https://playground.aussom-lang.com/

Try a few lines, then imagine that same interpreter embedded in your own Java app. I think you'll see the fit.

DEV Community: Austin Lehman