Ortus Solutions is excited to announce the open beta of MatchBox, a new open source project in the BoxLang ecosystem. MatchBox is a custom BoxLang virtual machine written in Rust. It is built for the places where a full JVM runtime is not the right fit: small native command-line tools, compact web services, browser applications, WebAssembly containers, and even embedded hardware like ESP32 devices.
The project started in early March and has been moving quickly - already at v0.5.0. That speed is part of why we are opening the beta now. MatchBox is already capable enough to build real experiments, prototypes, and early applications, but it is still beta software. APIs will change. Some language features are still being implemented. Some deployment targets are intentionally limited while we harden the runtime. We want developers to try it, break it, ask questions, and help shape where it goes next.
The repository is available now at https://github.com/ortus-boxlang/matchbox and the docs can be found here: https://boxlang.ortusbooks.com/boxlang-framework/matchbox
What Is MatchBox?
BoxLang already gives developers a modern, dynamic language with a familiar syntax, a growing module ecosystem, and multiple deployment styles on the JVM. MatchBox asks a different question:
What if BoxLang could also run without the JVM?
MatchBox is a Rust implementation of the BoxLang language toolchain. It includes a parser, compiler, bytecode format, stack-based virtual machine, cooperative fiber scheduler, and deployment tooling. You can run .bxs scripts directly with the MatchBox CLI, drop into an interactive REPL, compile scripts into portable bytecode (.bxb), or package that bytecode into standalone artifacts for different targets.
The goal is not to replace the JVM runtime. The goal is to add a new portable profile of BoxLang for cases where startup time, binary size, deployment simplicity, or hardware constraints matter.
In practical terms, MatchBox lets you write BoxLang and target:
- Native binaries for macOS, Linux, and Windows
- CLI applications with no external runtime dependency
- Web servers and routed HTTP apps
- Browser-focused JavaScript and WebAssembly bundles
- WASI workloads for edge and container-style environments
- ESP32 microcontrollers
JVM vs MatchBox - Two Runtime Profiles
These are not competing runtimes - they are two deployment profiles for the same language. Choose the one that fits the job:
┌─────────────────────────────────┐ ┌─────────────────────────────────┐
│ BoxLang (JVM Runtime) │ │ MatchBox (Rust VM) │
├─────────────────────────────────┤ ├─────────────────────────────────┤
│ Full language surface │ │ Strict BoxLang subset │
│ Full Java interop │ │ No JVM required │
│ Large standard library │ │ ~500 KB binary │
│ CFML compatibility layer │ │ Millisecond cold start │
│ JVM startup overhead │ │ WASM / browser support │
│ Ideal: web apps, APIs, ColdBox │ │ Ideal: CLI, edge, embedded │
└─────────────────────────────────┘ └─────────────────────────────────┘
│ │
└──────────────┬─────────────────┘
│
BoxLang language
(write once, target both)
✅ Code written for MatchBox generally runs unmodified on the JVM runtime. The reverse is not always true - the JVM runtime has a larger surface area.
A Custom BoxLang VM in Rust
At the center of MatchBox is a complete, self-contained language toolchain:
Your .bxs source file
│
▼
┌──────────────┐
│ Parser │ Pest PEG grammar → AST
└──────────────┘
│
▼
┌──────────────┐
│ Compiler │ Multi-stage → compact bytecode (.bxb)
└──────────────┘
│
▼
┌────────────────────────────────────────┐
│ MatchBox VM │
│ Stack-based bytecode execution │
│ Cooperative fiber scheduler │
│ Multi-tier JIT (Cranelift, native) │
└────────────────────────────────────────┘
│
├──▶ Native binary (macOS / Linux / Windows)
├──▶ WASM binary (browser / edge / WASI)
├──▶ JS ES module (browser + Node.js)
├──▶ ESP32 image (microcontroller)
└──▶ REPL / interpreted mode
The VM supports core BoxLang: variables, operators, string interpolation, conditionals, loops, functions, closures, arrays, structs, classes, inheritance, interfaces, exceptions, onMissingMethod, and async operations through a cooperative fiber scheduler.
MatchBox also includes a multi-tier JIT compiler for native CLI execution. The JIT is built on Cranelift and profiles hot code at runtime. It can optimize empty loops, numeric loops, float-array iteration, and hot computational functions when the bytecode is translatable. Unsupported code simply stays in the interpreter, so correctness does not depend on JIT coverage.
Different targets make different tradeoffs. The JIT is active in the native CLI, while native runner stubs, WebAssembly, and ESP32 builds stay lean and avoid carrying Cranelift where it does not make sense.
Multiple Deployment Targets
MatchBox uses a runner-stub architecture for native builds. The CLI compiles your BoxLang source to bytecode, appends that bytecode to a small precompiled runner, and produces a single ~500 KB executable. There is no JVM to install, no external loader, and no application server required for simple CLI tools.
matchbox --target native app.bxs
┌──────────────────────────────────────────┐
│ app (single binary) │
│ ┌─────────────────┐ ┌───────────────┐ │
│ │ Runner stub │ │ Your .bxb │ │
│ │ (~500 KB) │ │ bytecode │ │
│ └─────────────────┘ └───────────────┘ │
└──────────────────────────────────────────┘
No JVM. No installer. Ship it anywhere.
For browser workflows, MatchBox can compile BoxLang into a JavaScript ES module plus a .wasm file:
matchbox --target js todo.bxs
The generated module bootstraps the runtime, exposes top-level BoxLang functions as JavaScript exports, and registers itself under window.MatchBox. That means BoxLang can own application state while your HTML, Alpine.js, or other front-end code handles the UI. Inside the browser, your BoxLang code also gets direct access to JavaScript APIs and the DOM via js.* interop.
For lower-level WASM use cases, MatchBox can also produce a raw .wasm binary:
matchbox --target wasm service.bxs
That opens the door for WASI runtimes such as Wasmtime or WasmEdge, edge workloads, and minimal OCI-style WASM containers.
The web server target is another major area of work. MatchBox includes a static webroot/BXM server and a routed app-server model built around web.server(). The app server supports middleware, route groups, JSON responses, cookies, sessions, template rendering, static asset mounts, and signed webhook helpers.
And then there is ESP32. MatchBox can compile BoxLang bytecode and flash it to ESP32 devices. The embedded runner uses a dedicated flash partition for bytecode, supports fast redeploys after the initial full flash, and includes a watch mode for live development on hardware.
Native Fusion: BoxLang Meets Rust
One of the most interesting parts of MatchBox is Native Fusion.
Native Fusion lets you write performance-critical functions and stateful objects in Rust, then call them from BoxLang as first-class BIFs and native objects. The Rust code is statically linked into the final native binary - no shared libraries to ship, no FFI boilerplate in your BoxLang code.
⚠️ Native Fusion is available for
--target nativebuilds only. It is not supported in WASM or JS targets.
my-app/
├── app.bxs ← BoxLang entry point
└── native/
├── stats.rs ← register_bifs()
└── counter.rs ← register_bifs() + register_classes()
matchbox --target native app.bxs
┌─────────────────────────────────────────────┐
│ app (single binary) │
│ ┌───────────┐ ┌────────────┐ ┌────────┐ │
│ │ Runner │ │ BoxLang │ │ Rust │ │
│ │ stub │ │ bytecode │ │ BIFs │ │
│ └───────────┘ └────────────┘ └────────┘ │
└─────────────────────────────────────────────┘
Use Native Fusion when you need the strength of Rust inside a BoxLang application: fast parsing, compression, crypto, image processing, hardware integration, or access to Rust crates. Keep the application logic in BoxLang. Move the measured hot path or system integration point into Rust.
Bringing Java Along for the Ride
MatchBox is JVM-free by default - but that doesn't mean Java is completely off the table. For native builds, MatchBox ships an experimental JNI bridge (bif-jni): a dynamic JNI reflection bridge that handles automatic Java method discovery and invocation. It lets you call Java classes from BoxLang via createObject(), as long as a compatible JDK is present on the target machine.
MatchBox (native binary)
┌─────────────────────────────────────────────────────┐
│ Your BoxLang App │
│ │
│ obj = createObject( "java", "com.example.MyLib" ) │
│ result = obj.process( data ) │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Dynamic JNI Reflection Bridge (bif-jni) │ │
│ │ auto-discovers methods · handles invocation│ │
│ └──────────────────────┬───────────────────────┘ │
└─────────────────────────│───────────────────────────┘
│
▼
Host JDK (required at runtime)
Java class / library / SDK
This is an opt-in feature - not compiled into the standard MatchBox binary. You enable it at build time:
cargo build --release --features bif-jni
What works:
createObject( "java", "fully.qualified.ClassName" )- direct BIF callimport java:com.example.MyClassthennew MyClass()- import alias, compiler desugars tocreateObjectnew java:com.example.MyClass()- inlinejava:prefix, same desugar path- Automatic Java method discovery via reflection
- Basic method invocation on Java objects
What doesn't (yet):
- Java generics and annotations
- Dynamic JAR loading at runtime
- WASM or JS targets - JNI is native-only
⚠️ The JNI bridge requires a host JDK installed on the target machine at runtime. It is experimental and not recommended for production use yet.
Think of it as an escape hatch. If you have an existing Java library you absolutely need - a proprietary SDK, a legacy integration, a Java-only algorithm - the JNI bridge lets you reach it from MatchBox without abandoning the native deployment story entirely. For most use cases, Native Fusion Rust BIFs are the preferred path for performance-critical interop.
Still BoxLang
MatchBox is new, but it is not separate from the BoxLang story.
It uses BoxLang syntax. It supports the core language profile. It can discover modules from box.json, modules/, boxlang_modules/, matchbox.toml, and explicit --module paths. Pure BoxLang BIFs from modules can be injected and tree-shaken during compilation. Native MatchBox module support can expose Rust-powered BIFs and classes through the same module shape.
That means MatchBox can participate in the broader BoxLang and ForgeBox workflow, while still being honest about beta compatibility. Not every existing module will work unchanged on every target. JVM-specific features and Java libraries are outside the MatchBox profile. But the path is there: portable modules, native modules, and target-aware packages that let the ecosystem grow into new environments.
What's Different from BoxLang JVM?
MatchBox is a strict subset of BoxLang - most things work identically, but there are differences worth knowing before you dive in:
| Area | MatchBox | BoxLang JVM |
|---|---|---|
| Core language (variables, loops, closures, classes) | ✅ | ✅ |
| String / array / struct / math BIFs | ✅ | ✅ |
| JSON, File I/O, HTTP | ✅ | ✅ |
Async (runAsync, sleep) | ✅ | ✅ |
Java interop (createObject) | ⚠️ Experimental JNI (native only) | ✅ Full |
| Regular expressions | ❌ Coming soon | ✅ |
| Date/time functions | ⚠️ In progress | ✅ |
| Database / query | ⚠️ Experimental (PostgreSQL) | ✅ |
| CFML compatibility layer | ❌ | ✅ |
| WASM / browser support | ✅ | ❌ |
One-way compatibility: code written for MatchBox generally runs on the JVM runtime. The reverse is not always true.
For the full breakdown of what works, what's in progress, and how to write portable code across both runtimes, see the Differences from BoxLang JVM doc.
Getting Started
Linux / macOS:
curl -sSL https://raw.githubusercontent.com/ortus-boxlang/matchbox/master/install/install.sh | bash
Windows (PowerShell):
iex (Invoke-RestMethod -Uri https://raw.githubusercontent.com/ortus-boxlang/matchbox/master/install/install.ps1)
The installer will prompt you to choose between the Latest Release or Snapshot build.
Then run a script:
matchbox hello.bxs
Or drop into the interactive REPL:
matchbox
Or build a native binary:
matchbox --target native app.bxs
We also have starter templates for the first two common workflows:
- CLI template: https://github.com/ortus-boxlang/matchbox-cli-template
- Web server template: https://github.com/ortus-boxlang/matchbox-web-server-template
Where This Series Goes Next
This announcement is the first post in a MatchBox beta series. Each post will focus on one target, what works today, what is still beta, and where that target is headed:
- 👉 You are here - MatchBox Open Beta: BoxLang, Now Running in New Places
- Building Native CLI Apps with MatchBox and Native Fusion
- MatchBox Web Server: BoxLang Without the Full Server Stack
- MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge
- MatchBox on ESP32: BoxLang on Real Hardware!
MatchBox is already fun to build with. More importantly, it expands what BoxLang can be used for. It brings BoxLang to native executables, browser bundles, tiny server workloads, edge-style WASM, and physical devices.
That is the real announcement: BoxLang is no longer limited to one runtime shape. With MatchBox, the language can travel. Follow the project, try the beta, and open issues at https://github.com/ortus-boxlang/matchbox.
Join the Ortus Community
Be part of the movement shaping the future of web development. Stay connected and receive the latest updates on product launches, tool updates, promo services and much more.
Subscribe to our newsletter for exclusive content.
Follow Us on Social media and don't miss any news and updates:
Add Your Comment