Same bet, twenty years apart: a portable bytecode format run by a sandboxed virtual machine.
In 1995, Sun Microsystems built a slogan around a real engineering bet: compile once to bytecode, run that bytecode on a virtual machine wherever one exists, and stop rebuilding software for every operating system. “Write once, run anywhere” was the pitch, and the Java Virtual Machine was the vehicle. Twenty years later, four browser vendors who agreed on almost nothing else, Google, Mozilla, Microsoft and Apple, sat down to solve a version of the same problem: run untrusted code fast and safely on someone else’s machine, without shipping a different binary for every platform. The result, WebAssembly, is close enough to the JVM’s original bet that the comparison writes itself. It is also different enough, in ways shaped by thirty years of hindsight, that the two are worth placing side by side rather than treating as the same idea twice.
Same Ambition, Twenty Years Apart
The JVM’s promise shipped in 1995 as a complete package: a bytecode format, a managed heap with garbage collection, an object model, and a security sandbox, all bundled from day one. WebAssembly took a slower, more public road. Mozilla engineer Luke Wagner made the first design commits in April 2015, and on June 17, 2015, all four major browser vendors coordinated simultaneous blog posts announcing the project. The community group reached consensus on the initial binary format and JavaScript API in March 2017, and browsers began shipping it on by default within months, Firefox and Chrome that March, Safari that September, Edge in October. The W3C made it an official recommendation, the “fourth language of the web” alongside HTML, CSS and JavaScript, on December 5, 2019.
Both Are Stack Machines, But Not the Same Kind
Java bytecode and Wasm are both executed by pushing and popping an operand stack rather than juggling named registers, so the family resemblance is real. What differs is everything each format decided to carry with it from the start.
| JVM bytecode | WebAssembly (MVP) | |
|---|---|---|
| Type system | Full object model: classes, interfaces, arrays | Four numeric value types only (i32, i64, f32, f64) |
| Memory | Managed heap, garbage collected from day one | Raw linear memory the module manages itself |
| Verification | Bytecode verifier checks types and jumps at class-load time | Single linear pass; only structured blocks and loops, no arbitrary jumps |
| Typical origin | Interpreted, then JIT-compiled at run time | Usually compiled ahead of time from C, C++, or Rust |
Wasm’s restriction to structured control flow was a deliberate choice, documented in the project’s own design rationale, meant to make a module provably safe to run in a single, fast validation pass rather than the more elaborate verification the JVM needed to bolt on to catch bytecode that could jump anywhere. The trade is that Wasm shipped with no object model or garbage collector at all. Support for garbage-collected languages such as Kotlin and Java targeting Wasm directly did not land in all major browsers until the WasmGC proposal shipped in 2024, nearly a decade after the project began, and nearly thirty years after the JVM treated a managed heap as table stakes.
Where Wasm Wins the Race the JVM Started
Startup latency is the clearest gap, and it shows up wherever both formats get benchmarked under real conditions. A 2025 measurement of the Wasmtime runtime found an average cold-start time of 5.6 milliseconds for a no-op function and 16.9 milliseconds for a small compute-heavy one. A separate, independently run benchmark of AWS Lambda in late 2025 measured Java 25’s standard cold start at a median of 3,320 milliseconds, and, in a genuinely counterintuitive result, found that enabling SnapStart, AWS’s own optimization built specifically to fix Java cold starts, made things worse in that test, 5,463 milliseconds, apparently due to the overhead of restoring a snapshot and re-initializing connections. GraalVM’s ahead-of-time compiled native image, still built from the same JVM ecosystem, closed most of that gap on its own, landing at 425 milliseconds, right alongside Node.js at 430 milliseconds.
The Sandbox Story Nobody Expected
It is tempting to frame this as Wasm inventing safe sandboxing and the JVM catching up, but the history runs the other way. The JVM shipped its own capability-style sandbox, the Security Manager, from Java’s earliest releases, refined in Java 1.2 around the principle of least privilege. Oracle deprecated it for removal in Java 17 in 2021 via JEP 411, and disabled it functionally in 2024 under JEP 486, citing low real-world use and high maintenance cost. Wasm’s equivalent, a module that by default cannot touch a file, socket, or clock unless a host explicitly grants it that capability through WASI, is a younger, cleaner version of an idea the JVM had already tried, and largely walked away from, once it stopped being anyone’s priority.
Where the JVM Still Wins
None of this makes Wasm a strict upgrade. Its garbage-collected story is barely two years old against the JVM’s three decades of tuning across G1, ZGC, and Shenandoah. Its system-interface story, WASI, is still filling in basics; native asynchronous I/O using futures and streams only landed in WASI 0.3.0 in February 2026, closing what its own maintainers called the last major gap with conventional server runtimes. And a Wasm module, by design, is not a standalone program the way a .jar file is. It needs a host, a browser, a WASI runtime, an embedding application, to provide anything beyond pure computation, which makes its portability real but conditional on which host APIs that environment happens to expose. The JVM shipped the full “run anywhere” story, warts and all, as a single self-contained platform in 1995.
Reach for Wasm over the JVM when
- Cold-start latency or per-invocation footprint is the dominant cost, as in edge functions or plugin sandboxes
- The source language is C, C++, Rust, or another language that compiles ahead of time rather than one built around a managed heap
- The same untrusted module needs to run inside a browser and on a server from one build artifact
- A still-maturing garbage collector and standard library story for managed languages is an acceptable trade for the sandbox and startup profile
What We Learned
WebAssembly and the JVM answer the same question, how do you run code safely and portably without recompiling it for every machine, from opposite ends of thirty years of hindsight. The JVM bundled a full object model, a managed heap, and a sandbox into one platform in 1995 and later quietly deprecated the sandbox half of that promise. WebAssembly launched in 2015 with almost nothing but numeric types and a stack, then spent a decade adding back garbage collection, richer system interfaces, and asynchronous I/O one W3C proposal at a time. The result is a genuine trade rather than a clean win for either side: Wasm’s cold starts run in single-digit milliseconds where the JVM’s run in seconds, but the JVM’s managed runtime and standard library still cover more ground than Wasm’s still-filling-in system interface can match.
