Tutorial 1 — Hello, Fiji
Goal: run a Java program inside a WebAssembly component.
This is the smallest end-to-end demonstration of what Fiji is —
standard javac output running under a Wasm component runtime,
producing the output you'd expect.
What you need
wasmtimeon your PATH (a supported major version).- The Fiji release tarball extracted somewhere accessible.
- A WASI-targeted JDK image. The same one used by
fiji verify-releaseworks; export its path asFIJI_JDK_IMAGE.
The workload
HelloFiji.java:
public class HelloFiji {
public static void main(String[] args) {
System.out.println("Hello from Fiji.");
}
}
No special imports. No annotations. No Fiji-aware API surface.
The .class is produced by standard javac --release 21 and ships
alongside the source in the release tarball at
tutorials/01-hello-fiji/ so you don't need a host JDK to run the
tutorial.
Running it
From the tutorials/01-hello-fiji/ directory inside the release
tarball:
wasmtime run \
--dir=. \
../../components/fiji-jvm-composed.component.wasm \
HelloFiji
# → Hello from Fiji.
That's the whole demonstration. The same JAR-of-classes that would
run on java -cp . HelloFiji on a desktop JDK runs inside a
WebAssembly component on any host that speaks the component model.
What just happened
wasmtimeloaded the Fiji JVM component (fiji-jvm-composed.component.wasm).- The host (
wasmtimehere, via WASI) handed Fiji the workload class name (HelloFiji). - Fiji's runtime — a real JVM, packaged as a Wasm component —
resolved the class, executed the bytecode, and the
printlncall wrote bytes through standard WASI stdio.
No JNI. No platform-specific binary. No transpilation. The same
.class file would run identically on any JDK.
Going further
The release tarball ships a second tutorial,
05-same-artifact-several-runtimes/,
showing the same workload + the same component artifact running
under multiple host categories — standalone Wasmtime, Node via
jco, with pointers to browser and embedded-library hosts.