Embedding Guide
One entry point works everywhere. The JVM gets extra integrations on top, because
that's where luak-jvm
can afford to reach for platform-specific APIs.
Every target
LuaPlatform.standardGlobals() builds a fully loaded Globals
on JVM, Kotlin/Native, JS and Wasm alike. Loading and calling a chunk looks the same
regardless of target.
import org.basaltmc.luak.lib.LuaPlatform
val globals = LuaPlatform.standardGlobals()
globals.load("print('hello, world')")!!.call()JVM: luajava, scripting and the JIT
luak-jvm adds JvmPlatform.standardGlobals(), luajava
for calling Java from Lua and back, io.popen and os.execute
for process control, the luajc JIT compiler, CLI tooling, and a
javax.script engine for hosts that already speak that interface.
Architecture
The Lua runtime, value model, bytecode compiler and standard libraries live in
commonMain. Platform-dependent functionality is exposed through
expect/actual implementations, and Java or JVM APIs stay
confined to JVM source sets and luak-jvm: no type in the public
commonMain API is platform-specific.
| Source set or module | Purpose |
|---|---|
luak-core/commonMain |
Shared Lua runtime, compiler and libraries |
luak-core/jvmMain |
JVM implementations of platform abstractions |
luak-core/nonJvmMain |
Portable implementations shared by JavaScript and Wasm |
luak-core/jsHostMain |
JavaScript-host implementations (node:fs, process) for JS and Wasm-JS |
luak-core/wasmWasiMain |
WASI implementations over raw wasi_snapshot_preview1 syscalls |
luak-core/nativeMain |
Kotlin/Native implementations of platform abstractions |
luak-jvm |
JVM-only integrations and command-line tooling |
The host surface every shared library is built on is deliberately small: console streams, resource lookup, a random-access file handle, delete or rename or temp-name, environment variables, exit, GC, and weak references. Everything else, the value model, the compiler, and all nine standard libraries, is shared code.