GraalVM + WASM from the Perspective of a J2CL/GWT Developer

I recommend watching the talk “The Future of Write Once, Run Anywhere: From Java to WebAssembly” by Patrick Ziegler & Fabio Niephaus for additional context.

For a long time, GWT and later J2CL were the primary methods for building complex web appl…


This content originally appeared on DEV Community and was authored by Dmitrii Tikhomirov

I recommend watching the talk “The Future of Write Once, Run Anywhere: From Java to WebAssembly” by Patrick Ziegler & Fabio Niephaus for additional context.

For a long time, GWT and later J2CL were the primary methods for building complex web applications in Java. However, many of the original GWT use cases (dating back almost 20 years) are now obsolete. At the same time, the emergence of frameworks like React and the TypeScript language raises the question: is it still worthwhile to use such a niche solution?

One of the main drawbacks of both GWT and J2CL is that they require source code compatible with their jre/supported features in order to produce JavaScript. As a result, very few libraries are available, because you have to either port existing ones (and then maintain them) or develop them from scratch, which is quite time-intensive.

I personally dedicated a substantial amount of time to building several core GWT/J2CL libraries—JSON, YAML and XML marshallers plus a dependency‐injection framework, but such an investment is difficult to justify from a business standpoint, as no stakeholder is likely to underwrite that level of development effort.

When I learned that the Oracle GraalVM Team is working on WebAssembly compilation, it immediately caught my attention: one of the standout features is that bitecode is used as the build input. Although not all features are supported yet (for example, multithreading is not available due to current WebAssembly limitations), it was worth experimenting.

After trying a few sample projects, I found:

✔ Setup and build

No special configuration required: everything works within a standard Maven environment (using an Oracle GraalVM Early‐Access build)

Build steps mirror those for GraalVM native images

✔ Runtime features

  • Reflection support (classes must be registered in reflect-config.json)
  • ServiceLoader support
  • CLDR support (e.g. DateTimeFormatter works without hacks; full date/time and time-zone handling)
  • String.format works :) (unavailable in J2CL/GWT)
  • Several XML/JSON marshallers run out of the box
  • In other words, mostly any libraries will work out of the box.

✘ Current limitations

  • No direct DOM access: JsInterop exists in an early stage and is not yet suitable for GUI construction (improvements promised)
  • WASM exports not yet functional, though a fix is pending via pull request
  • No source-map support, making debugging difficult
  • No threading, networking or graphics support (expected at this stage)

To test a real-world scenario, I compiled and ran Drools - a Business Rule Management System and rules engine. In a standard JVM setup, Drools compiles DRL into .class files at runtime, loads them and uses them for validation. Because native images cannot load classes dynamically (though this may change soon), I moved DRL rules into a separate module and precompiled them with kie-maven-plugin. I also adjusted Drools to handle resource reading inlined into WASM. As usual, I added classes and resources to reflect-config.json, resource-config.json and native-image.properties.

Result: Drools runs in the browser as a .wad file; the complete application size is 41 MB, and a single rule executes in 6 ms.

The GraalVM Team claims that WASM compilation is production-ready, but tooling (for example, exports) is not fully mature. Overall, however, this looks very promising. I see huge potential for running large Java applications in WebAssembly. I’m particularly interested in the WebAssembly Component Model, which could enable assembling applications like LEGO, each component written in its own language. Challenges remain, but progress is encouraging.

I will continue to monitor GraalVM WASM development closely. If I discover further insights, I will report them here.


This content originally appeared on DEV Community and was authored by Dmitrii Tikhomirov


Print Share Comment Cite Upload Translate Updates
APA

Dmitrii Tikhomirov | Sciencx (2025-07-11T06:15:00+00:00) GraalVM + WASM from the Perspective of a J2CL/GWT Developer. Retrieved from https://www.scien.cx/2025/07/11/graalvm-wasm-from-the-perspective-of-a-j2cl-gwt-developer/

MLA
" » GraalVM + WASM from the Perspective of a J2CL/GWT Developer." Dmitrii Tikhomirov | Sciencx - Friday July 11, 2025, https://www.scien.cx/2025/07/11/graalvm-wasm-from-the-perspective-of-a-j2cl-gwt-developer/
HARVARD
Dmitrii Tikhomirov | Sciencx Friday July 11, 2025 » GraalVM + WASM from the Perspective of a J2CL/GWT Developer., viewed ,<https://www.scien.cx/2025/07/11/graalvm-wasm-from-the-perspective-of-a-j2cl-gwt-developer/>
VANCOUVER
Dmitrii Tikhomirov | Sciencx - » GraalVM + WASM from the Perspective of a J2CL/GWT Developer. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2025/07/11/graalvm-wasm-from-the-perspective-of-a-j2cl-gwt-developer/
CHICAGO
" » GraalVM + WASM from the Perspective of a J2CL/GWT Developer." Dmitrii Tikhomirov | Sciencx - Accessed . https://www.scien.cx/2025/07/11/graalvm-wasm-from-the-perspective-of-a-j2cl-gwt-developer/
IEEE
" » GraalVM + WASM from the Perspective of a J2CL/GWT Developer." Dmitrii Tikhomirov | Sciencx [Online]. Available: https://www.scien.cx/2025/07/11/graalvm-wasm-from-the-perspective-of-a-j2cl-gwt-developer/. [Accessed: ]
rf:citation
» GraalVM + WASM from the Perspective of a J2CL/GWT Developer | Dmitrii Tikhomirov | Sciencx | https://www.scien.cx/2025/07/11/graalvm-wasm-from-the-perspective-of-a-j2cl-gwt-developer/ |

Please log in to upload a file.




There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.