Compiling JDK to JavaScript

[kerbymart]

Hi! I'm working on reviving an old and abandoned repository for a special project I'm pursuing. I managed to build the decade-old teavm-javac project in 2025, which already feels like a significant accomplishment. The project depended heavily on snapshot versions with specific revisions, including langtools that I retrieved from JetBrains’ repository. Despite the original Mercurial repositories being long gone, the build was ultimately successful.

However, I encountered the following runtime error:

Uncaught ReferenceError: Oxp is not defined
    at classes.js:38166:228
    at classes.js:38677:3
    at worker.js:1:6

This occurs in a worker script where I have:

self.importScripts("teavm/worker/classes.js");
main();

Now I'm at a crossroads: is it worth spending the time debugging this error to get a working demo, or would it be more practical to use the latest version of TeaVM with a modern JVM language?

Any thoughts or advice would be appreciated!

P.S.
A question for the community: has anyone attempted to compile the JDK into JavaScript and run it in the browser? I’d love to hear about your experience—what worked, what didn’t, and whether you found it worthwhile.

[konsoletyper]

I'm just working on the same task: reviving this project. I actually managed to do this with Java 21 compiler and recent TeaVM version. Just wait until I publish everything. Or you can checkout reviving branch and try to build compiler module. Try to figure out how to to that. And there is index.html page there that I temporarily use for testing. Also, note that you need to build WebAssembly GC version (I did not test it with JS and not going to).

[kerbymart]

I tried to build it with 0.12.1 since I don't have the 0.13.0 snapshot but not compatible api, I mean TeaVM master is not building on my Mac I will try to fix this first.

[kerbymart]

I managed to build the compiler module earlier but index in throwing:

Failed to load resource: the server responded with a status of 404 (Not Found)
compiler.wasm-runtime.js:207 Uncaught (in promise) JavaError: (could not fetch message)
    at decorateException (compiler.wasm-runtime.js:207:13)
    at java.lang.Throwable::fillInStackTrace (TThrowable.java:121:1)
    at java.lang.Throwable::<init> (TThrowable.java:70:1)
    at java.lang.Exception::<init> (TException.java:22:1)
    at java.lang.RuntimeException::<init> (TRuntimeException.java:25:1)
    at java.lang.NullPointerException::<init> (TNullPointerException.java:26:1)
    at org.teavm.backend.wasm.runtime.gc.WasmGCSupport::npe (WasmGCSupport.java:27:1)

/compiler.wasm.teadbg <-- Not generated.

[kerbymart]

Is it throwing or gracefylly reporting? At what step? Did you successfully generate JS which produces this error during work OR you receive this message during compilation process?

Also, what's the purpose of generating JS when you have WebAssembly?

This is during the buildWasmGC

WebAssembly can't access the browser DOM natively/directly. Our use-case is to manipulate the DOM from compiled code in the browser.

[konsoletyper]

This is during the buildWasmGC

But is this exception or just graceful error reporting?

WebAssembly can't access the browser DOM natively/directly

No, you can access browser DOM natively from WebAssembly.

[kerbymart]

No, you can access browser DOM natively from WebAssembly.

So this should work and be able to access the DOM?

import org.teavm.jso.dom.html.HTMLDocument;

public class MainClass {
    public static void main(String[] args) {
        var document = HTMLDocument.current();
        var div = document.createElement("div");
        div.appendChild(document.createTextNode("TeaVM generated element"));
        document.getBody().appendChild(div);
    }
}

I have not tested this since the teavm javac wasm can't compile this,

[konsoletyper]

This should work. As I said, currently this javac-revival is in a very early prototype stage. "Normal" TeaVM should support JSO without any problem.

Also, I'd correct myself saying "WebAssembly supports direct DOM manipulation". There are no instructions to support DOM right in WebAssembly, but you can import any DOM instructions directly into WebAssembly binary and call it as a function, you can pass JS objects into WebAssembly function and vice versa. So effectively you can observe it as if WebAssembly manipulated DOM directly.

[konsoletyper]

@kerbymart I pushed my recent changes to the master branch and published demo here: https://teavm.org/playground/

Still a lot of work to do, but at least now JSO is supported

[konsoletyper]

has anyone attempted to compile the JDK into JavaScript and run it in the browser

BTW, what do you mean by this? With TeaVM it's definitely not possible and it's not a goal for this project. CheerpJ is much closer to "compile JDK into JS and run it in the browser", but they do a lot of hacks to do that, and also has their drawbacks.

[kerbymart]

Ah, yeah—our project’s definitely not trying to do that. Even running a basic “hello world” with Cheerp is already too slow. Their goal seems to be more about getting any Java app running in the browser, which is a different direction. What we’re after is near-native Java performance in the browser, even if it means giving up full access to the standard Java APIs and libraries. The big thing for us is being able to manipulate the DOM with Java—basically using Java like you would JavaScript in the browser.

To make that work, we need a way to compile Java code in the browser and then translate it to JavaScript. I came across this Graal project (javac in the browser: [https://graalvm.github.io/graalvm-demos/native-image/wasm-javac/]), and it’s impressively fast—but I think the license might be a bit restrictive. Either way, the compiled bytecode still needs to be translated to JS.

We’ve explored a bunch of bytecode-to-JS tools, and so far only TeaVM offers real, first-class access to the browser DOM. Most others are focused on just “running Java programs in the browser,” whereas our goal is more about “manipulating the DOM using Java”—basically treating Java like JavaScript in the browser.