GraalRuntime

The GraalJS execution engine — the "real JavaScript" path. A JIM module's TypeScript is first transpiled to JavaScript by swc4j (here used as a plain TS→JS transpiler, not its bytecode compiler) and then evaluated as an ES module on a GraalJS Context. Scripts get full ECMAScript: real arrays with .map/.filter, closures over reassigned lets, objects, JSON, etc. — none of the bytecode path's "half-Java" workarounds (Store/Num/Args).

The JIM API objects (Jim, Event, ChatLib, ...) are bound as JS globals, so the familiar import { Jim, Event } from 'ratph6.jim.api' line is simply stripped before evaluation (the names resolve to the globals instead).

Single-threaded by construction: the Context is created on, and only ever touched from, the JS thread — which is also where module loading, dispatch and timers run. This matches GraalJS's single-thread-at-a-time contract; no locking needed.

Security: host access is broad on the bound objects, but allowHostClassLookup is left off, so guest code cannot reach Runtime/ProcessBuilder/etc. — only the bound API surface and whatever it returns. Mirrors the intent of JimCompiler's import ban.