Forem: Dmitrii Tikhomirov

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

Dmitrii Tikhomirov — Fri, 11 Jul 2025 06:15:00 +0000

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.

Java for web frontend developers, part 2: getting started with J2CL

Dmitrii Tikhomirov — Mon, 06 Jun 2022 23:47:34 +0000

In the previous article I described how to create and run a simple Java application in a web browser using j2cl-maven-plugin, so if you aren’t familiar with J2CL or Google Closure Compiler I’d recommend taking a look at that article first.

In this article I’m going to show you 3 scenarios of running J2CL applications:

1) Running our app as a standalone application
2) Calling methods of our application from JavaScript via a window object
3) Exporting methods from our Java to JavaScript environment

Before we begin:

In the examples below, I'll be rewriting parts of the demos code. To try out complete demos you can check my GitHub repo that contains all demos in one place.

If you have questions about running the demos, check my previous article.

1) Standalone applications

First, I created a simple POJO called User.java with several properties inside and a simple form with corresponding inputs that were passed to the properties of the POJO. To marshall an instance of User to XML I’ll be using the mapper-xml project. It’s an implementation of JAXB (Java Architecture for XML Binding) for GWT and J2CL. I like JAXB because it’s very flexible and allows us to process complex XML structures by annotating Java Beans.

@XMLMapper
public class User {

   private String firstName;
   private String secondName;
   private int age;

… getters and setters omitted

@XMLMapper is necessary here to trigger a JAXB annotation processor to generate the User_XMLMapperImpl marshaller for this POJO. User_XMLMapperImpl can be used to serialize and deserialize User to XML and back.

public class App {

 private AbstractObjectMapper mapper = User_XMLMapperImpl.INSTANCE;

 public void onModuleLoad() {

   HTMLDivElement xmlDivElement = (HTMLDivElement) DomGlobal.document.getElementById("xml");

   HTMLButtonElement submit = (HTMLButtonElement) DomGlobal.document.getElementById("submit");
   HTMLInputElement firstName = (HTMLInputElement) DomGlobal.document.getElementById("firstName");
   HTMLInputElement secondName =
       (HTMLInputElement) DomGlobal.document.getElementById("secondName");
   HTMLInputElement age = (HTMLInputElement) DomGlobal.document.getElementById("age");

   submit.addEventListener(
       "click",
       evt -> {
         try {
           User user = new User();
           user.setFirstName(firstName.textContent);
           user.setSecondName(secondName.textContent);

           String _age = age.textContent.trim();
           user.setAge(Integer.parseInt(age.value.trim()));

           String xml = mapper.write(user);
           xmlDivElement.textContent = xml;

           $("#exampleModal").modal("show");

         } catch (Exception e) {
           DomGlobal.alert("Exception " + e.getMessage());
         }
       });
 }
}

As you can see, I have added a listener to the submit button that collects values from the fields and sets them to the instance of the User object. When it’s done I call a mapper, which is an instance of the User’s marshaller, pass User into it and print the resulting XML on the screen. Simple and nice.

2) Calling an XML marshaller from an existing application

Let’s say, we already have an existing JavaScript application and we want to add an XML export feature to it.

var User = function () {
   this.firstName =  '';
   this.secondName =  '';
   this.age = -1;
}

The User object from the existing JavaScript application should be bound to the existing User.java, which is its representation in Java. To achieve that we need to do 2 steps. First, we add the @JsType annotation to the User (@JsType is part of the JsInterop API of J2CL and definitely deserves a separate article):

@XMLMapper
@JsType(isNative = true, namespace = JsPackage.GLOBAL, name = "User")
public class User {

   private String firstName;
   private String secondName;
   private int age;

Secondly, we have to tell the Closure Compiler that a JavaScript User object exists in the global scope and it has to deal with it, so I added an extern (something like d.ts from TS) for it:

/**
* @externs
*/

/**
* @constructor
*/
var User = function () {}

/**
* @type {string|undefined}
*/
User.prototype.firstName;

/**
* @type {string|undefined}
*/
User.prototype.secondName;

/**
* @type {number|undefined}
*/
User.prototype.age;

The next step is to publish our marshaller to make it discoverable from JavaScript:

public class App {

 private AbstractObjectMapper mapper = User_XMLMapperImpl.INSTANCE;

 public void onModuleLoad() {
   Js.asPropertyMap(DomGlobal.window)
       .set(
           "toXml",
           (OnCall)
               user -> {
                 String xml = null;
                 try {
                   xml = mapper.write(user);
                 } catch (Exception e) {
                   DomGlobal.alert("Exception " + e.getMessage());
                 }

                 return Promise.resolve(xml);
               });
 }

 @JsFunction
 private interface OnCall {

   Promise<String> invoke(User user);
 }
}

As you can see, I created the OnCall function. It will receive a JavaScript User object, pass it to the marshaller and return a Promise<String> with a resulting XML. I bind this function to a window object using the property name toXML. So all we need is to call it from JavaScript, like this:

$("#submit").on( "click", function() {

   var user = new User();
   user.firstName =  $('#firstName').val();
   user.secondName =  $('#secondName').val();
   user.age = $('#age').val();

   window.toXml(user).then(function (result) {
       $(".modal-body #xml").text(result);
       $('#exampleModal').modal('show');
       }
   );
});

3) Using Google Closure Compiler to export methods to JavaScript

The Closure Compiler has very powerful ways to simplify interoperability with an existing JavaScript environment. To simplify its usage even further I created a project that helps with it. All we need is to add the following Maven dependencies and annotate the method we want to export with the @GWT3Export annotation, like I did here:

<dependency>
   <groupId>org.treblereel.j2cl.processors</groupId>
   <artifactId>annotations</artifactId>
   <version>0.4.1</version>
</dependency>
<dependency>
   <groupId>org.treblereel.j2cl.processors</groupId>
   <artifactId>processors</artifactId>
   <version>0.4.1</version>
   <scope>provided</scope>
</dependency>

public class App {

 private AbstractObjectMapper mapper = User_XMLMapperImpl.INSTANCE;

 @GWT3Export
 public Promise<String> toXml(User user) {
   String xml = null;
   try {
     xml = mapper.write(user);
   } catch (Exception e) {
     DomGlobal.alert("Exception " + e.getMessage());
   }

   return Promise.resolve(xml);
 }
}

The very last thing left: call it for the JavaScript:

<script>

   var marshaller = new org.treblereel.j2cl.helloworld.App();

   var User = function () {
       this.firstName =  '';
       this.secondName =  '';
       this.age = -1;
   }

   $("#submit").on( "click", function() {

       var user = new User();
       user.firstName =  $('#firstName').val();
       user.secondName =  $('#secondName').val();
       user.age = $('#age').val();

       marshaller.toXml(user).then(function (result) {
           $(".modal-body #xml").text(result);
           $('#exampleModal').modal('show');
           }
       );
   });

</script>

In this article I have shown you a few examples of how we can deal with applications written in Java and compiled to JavaScript with the help of the J2CL Maven plugin. There are many topics I would like to touch upon in my upcoming articles from the low-level ones like writing externs and using the JsInterop API, to the high-level ones like modern UI libraries and advanced frameworks.

If you like my articles, feel free to join GWT and J2CL channels, follow me on Twitter, LinkedIn or GitHub or even support me on Patreon or Stripe.

Java for web frontend developers, part 1 : generating a simple project

Dmitrii Tikhomirov — Mon, 06 Jun 2022 23:46:15 +0000

Disclaimer: Initially this article has been published by me on blog.kie.org. I republish it here with their permission.

It looks like 15 years of GWT are coming to the end, and besides that web development has dramatically changed since 2006. There is now no chaos of conflicting browser implementations that require to run multiple permutations each. At the same time modern web development frameworks are far from ideal. For instance, a very strong advantage of GWT was the ecosystem around Maven – the stability and usability of this solution was incredible, especially when big teams worked on large projects.

Google, the main developer of GWT, left the project and started J2CL, the successor of GWT, which takes the very best practices to a new level. Their documentation calls it out as being used in many high performance projects such as Gmail, Inbox, Docs, Slides, and Calendar.

Initially J2CL was developed to be used in the Bazel environment. After several years of hard work the community, led by Colin Alworth, released the first public J2CL version for Maven – J2CL Maven plugin.

So let’s take a look at what it is and how it works.

J2CL AND CLOSURE COMPILER
J2CL is responsible for only one task – to transpile a set of Java classes into a set of JavaScript files.

Google’s Closure Compiler is responsible for merging this set of javascripts into one executable JS script, its optimization and minification.

Closure Compiler is extremely efficient in minification and optimization of the JavaScript, it simply has no competitors.

GENERATING OUR FIRST J2CL PROJECT
Let’s start from a simple one module application. Luckily for us, we can generate it from a pre-build archetype. Download the archetype if you don’t have it:

mvn org.apache.maven.plugins:maven-dependency-plugin:get \
-DrepoUrl=https://repo.vertispan.com/j2cl/ \
-Dartifact=com.vertispan.j2cl.archetypes:j2cl-archetype-simple:0.19

Now we can generate a simple application:

mvn archetype:generate -DarchetypeGroupId=com.vertispan.j2cl.archetypes \
-DarchetypeArtifactId=j2cl-archetype-simple \
-DarchetypeVersion=0.19

Let’s take a look at the result:

├── pom.xml
└── src
    ├── main
    │   ├── java
    │   │   └── org
    │   │       └── treblereel
    │   │           └── j2cl
    │   │               ├── App.java
    │   │               └── App.native.js
    │   └── webapp
    │       ├── WEB-INF
    │       │   └── web.xml
    │       ├── css
    │       │   └── simpleapp.css
    │       └── index.html
    └── test
        └── java
            └── org
                └── treblereel
                    └── j2cl
                        └── AppTest.java

– App.java is a starting point of our application and there’s one point I have to highlight below.

– App.native.js used to specify how to start our application to the Closure Compiler, because it knows nothing about it. Usage of native.js is a very large topic and a separate article can be written about it.

– AppTest.java is just a J2CL-compatible unit test that runs in HtmlUnit, it’s also possible to use ChromeDriver to run it in a real browser but it takes longer.

– pom.xml – here the only interesting part for us is the j2cl-maven-plugin section. For now it contains only the <compilationLevel> declaration used to set which level of optimization we are going to use during the compilation of the project. ADVANCED is the most efficient one, so Closure Compiler does aggressive renaming, dead code removal, global inlining and so on. But in some cases Closure Compiler needs our help and care – we have to declare which properties or methods should not be removed or renamed. BUNDLE is less strict and better suitable for development because each compilation round takes less time compared to ADVANCED.

RUNNING AND BUILDING OUR J2CL APPLICATION
j2cl-maven-plugin allows us to run our application in the development mode with build-in hot code reload and source map debug. To start devmode, run the following command in the terminal:

mvn j2cl:watch
When the application started, run the following command in the second terminal:

mvn jetty:run
There is no need to run mvn clean each time because J2CL will recompile everything from scratch, and we can reuse the results from the previous run. Moreover, there is an option to use global cache between several projects to reduce compilation time.

To build .war we should run mvn package, there is nothing new here, everything is pretty familiar to GWT developers.

OK, WHAT IS NEW COMPARED TO GWT

GWT modules are gone, yes, no more modules. So J2CL will try to compile direct and transitive dependencies from pom.xml, that is why we should set provided scope to annotation processors and shade them.
GWT.create gone as well
GWT generators are gone, now we should use APT-based generators.
What about GWT components and widgets we used before ? Most of them have been ported to J2CL.
Does @GwtIncompatible work? Yes, it is still here.

AND WHAT IS THE VALUE OF IT FOR US?
Right now we are focused on migration of our existing projects from GWT2 to J2CL. There are many libraries that have been migrated to J2CL and many other libraries support both GWT2 and J2CL. I'd like to highlight elemental2-* wrappers, DominoKit, Nalu, and many others.
GWT2 has been ported as the GWT Project which is a set of migrated modules. The Errai project, once a very popular dependency injection framework, is the core component of applications we use internally. Errai has been re-implemented as the Crysknife project.

In the upcoming posts I'm going to address several topics:

Existing libraries and frameworks that are J2CL-compatible
Defines – how to propagate variables to J2CL
How we can improve generated code with native.js
Externs – why do we need them and how to write our own externs
Semi-reflection
Interoperability with TS
And maybe many more

If you like my articles, feel free to join GWT and J2CL channels, follow me on Twitter, LinkedIn or GitHub or even support me on Patreon or Stripe.

Three.js for Java devs: J2CL, Closure, Bazel, etc ...

Dmitrii Tikhomirov — Thu, 30 Dec 2021 06:05:38 +0000

Let's say we really want to write web-based applications on Java using webgl/webxr/webgpu or something. What options do we have?

GWT

The first approach that comes to mind would be using GWT by Google. When it launched 15 years ago, GWT instantly grew very popular and gave rise to many amazing frameworks based on it, like Vaadin, Ext GWT/GXT, Smart GWT, and many others. But it looks like its time has finally come: Google left the GWT project passing it to the community.

If not GWT

If not GWT, there are a few not very active and popular projects like JSweet (a syntax mapper to TypeScript) or TeaVM that’s rather dead according to GitHub activity. Not to worry about our project in the future, we would probably choose something stable and well-maintained.

J2CL

There aren’t many options left, but, luckily for us, we can take a look at J2CL, a Java to Closure style JavaScript transpiler, that is a GWT successor. According to Google, J2CL is widely used in many projects such as Gmail, Inbox, Docs, Slides, and Calendar. At first glance, it’s exactly what we need, but there’s one little problem - it heavily depends on Bazel that differs a lot from our favourite good old Maven.

J2CL is responsible for only one task – to transpile a set of Java classes into a set of JavaScript files. Merging this set of javascripts into one executable script, its optimization and minification is the responsibility of Google’s Closure Compiler.

Google loves Bazel (yeah, a monorepo, reproducible and stable builds and so on), we usually use Maven or Gradle for our projects. Luckily, we can try j2cl-maven-plugin that is developed by Colin Alworth from Vertispan, but for now let’s try the Bazel way.

J2CL with Bazel

First steps with Bazel are pain. What’s good, we can reuse 2 samples provided by the J2CL project, these 2 demos are more than enough to get us started. In short, the most important Bazel rules for us are j2cl_library and j2cl_application that can be used to set groups of files and transpile them into an executable JavaScript file. But for it to work one more step is required: we need to define an entry point for our application. It can be done in 2 ways: we can define it with a handwritten JavaScript script like it works in J2CL demos, or we can generate it with an annotation processor I wrote for this purpose, feel free to take a look at the demo too.

TIP: For more details on j2cl_library and j2cl_application, you could take a look at an amazing article by Thomas Broyer.

OK, so far so good. My favorite IDE is IntelliJ IDEA that has an official Bazel plugin by Google, but if you prefer VS Code you could try a plugin developed by salesforge.

Native APIs

To work with browser APIs from Java we would use Elemental2, which is abstractions for JavaScript APIs, the set of Java wrappers based on the Closure Compiler externs.

Externs are type definitions of, for instance, Browser APIs like HTML elements or WebGL classes, pretty much the same as d.ts, that helps Closure Compiler to recognize the types. By the way, Elemental2 libraries were generated from the built-in Closure Compiler externs using the JsInterop generator. Elemental2 does not cover the whole set of Web APIs, but it’s not too difficult to write missing parts like I did in my research project.

TIP: Peter Donald is working on an impressive project Akasha that aims at creating a unified set of APIs generated from the latest WebIDL specs. It’s kept mostly up-to-date but is incompatible with Elemental2 (as a matter of fact, it’s incompatible with the built-in Closure externs).

JsInterop

So it looks like we have pretty much everything except for the most important part: three.js that we can use from Java. And it’s a little bit of a complex part. To interop with JavaScript we should use J2CL JsInterop API, but there is a little problem: Closure Compiler must be able to recognize types of (most of the) three.js objects. Here we have two options:

Annotate source classes of three.js by Closure type annotations and do some refactoring (Uniforms is pain).
Advantages: During the optimization phase, Closure Compiler does tree shaking, function inlining and other optimization and other techniques to reduce resulting JavaScript file size. It’s the smallest and fastest option.
Disadvantages: Adding type annotations to such a huge library like three.js is time-consuming and difficult. From my experience, it needs huge refactoring and is very difficult to maintain. Creating a proof of concept took me two months of hard work.
Use pure three.min.js as is, load it via a JavaScript injection or script tag.
Advantages: Easy to maintain.
Disadvantages:
i. Total code size will be three.min.js + your app code.
ii. We need externs to generate Java abstractions and make Closure Compiler happy.
iii. But there is no externs for three.js.

Externs

So I chose the last option: using pure three.min.js. After some googling I found a well-supported d.ts – TypeScript declaration files for three.js by the DefinitelyTyped project.

Well, sounds nice, writing externs from scratch for such a huge project like three.js is an overwhelming task for one person. But there was a little problem: how to convert d.ts to externs? The good news: we can use Tsickle, the project aimed at generating externs from d.ts.

Tsickle

The bad news for me was that after generation the resulting externs didn’t work. It took me a few hours to fix namespace and types issues, and enums had to be replaced by constants, I had no choice, enum support in J2CL is limited now. According to J2CL GitHub issues page, the team is working to improve it in the nearest future.

JsInterop generator

OK, after three.js externs started to work almost as expected (well enough for the time being), I generated Java @JSType based on those externs and finished the demo.

Demo

You can take a look at the demo here:
https://static.treblereel.org/bazel-three4g

The source code is published here:
https://github.com/treblereel/bazel_three_demo

Here is how the working Demo class looks like:

package demo;

import elemental2.dom.DomGlobal;
import org.treblereel.gwt.elemental2.three.BoxGeometry;
import org.treblereel.gwt.elemental2.three.Mesh;
import org.treblereel.gwt.elemental2.three.MeshBasicMaterial;
import org.treblereel.gwt.elemental2.three.MeshBasicMaterialParameters;
import org.treblereel.gwt.elemental2.three.PerspectiveCamera;
import org.treblereel.gwt.elemental2.three.Scene;
import org.treblereel.gwt.elemental2.three.Texture;
import org.treblereel.gwt.elemental2.three.TextureLoader;
import org.treblereel.gwt.elemental2.three.WebGLRenderer;
import org.treblereel.gwt.elemental2.three.WebGLRendererParameters;

public class Demo {

    private PerspectiveCamera camera;
    private Scene scene;
    private Mesh mesh;
    private WebGLRenderer renderer;

    Demo() {
        camera = new PerspectiveCamera( 70, DomGlobal.window.innerWidth / DomGlobal.window.innerHeight, 1, 1000 );
        camera.position.z = 400;
        scene = new Scene();
        Texture texture = new TextureLoader().load("https://threejs.org/examples/textures/crate.gif" );
        MeshBasicMaterialParameters meshBasicMaterialParameters = MeshBasicMaterialParameters.create();
        meshBasicMaterialParameters.setMap(texture);

        BoxGeometry geometry = new BoxGeometry(200, 200, 200 );
        MeshBasicMaterial material = new MeshBasicMaterial(meshBasicMaterialParameters);

        mesh = new Mesh( geometry, material );

        scene.add( mesh );

        WebGLRendererParameters webGLRendererParameters = WebGLRendererParameters.create();
        webGLRendererParameters.setAntialias(true);

        renderer = new WebGLRenderer(webGLRendererParameters);
        renderer.setPixelRatio( DomGlobal.window.devicePixelRatio );
        renderer.setSize( DomGlobal.window.innerWidth, DomGlobal.window.innerHeight );
        DomGlobal.document.body.appendChild( renderer.domElement );

        DomGlobal.window.addEventListener("resize", evt -> onWindowResize(), false);

        animate();
    }

    private void  onWindowResize() {

        camera.aspect = DomGlobal.window.innerWidth / DomGlobal.window.innerHeight;
        camera.updateProjectionMatrix();

        renderer.setSize( DomGlobal.window.innerWidth, DomGlobal.window.innerHeight );
    }

    private void animate() {
        DomGlobal.requestAnimationFrame(timestamp -> animate());
        mesh.rotation.x += 0.005;
        mesh.rotation.y += 0.01;
        renderer.render( scene, camera );
    }
}

Conclusion

Bazel with J2CL works great for such tasks, Bazel is very fast!
It’s not difficult to maintain a Java three.js wrapper, we only need to keep externs updated.
A huge minus is that testing is not opensourced yet, but j2cl-maven-plugin works around it.
Source map for debugging doesn’t work (it’s reported at J2CL and Closure GitHub issues page). Perhaps it’s possible to use Vertispan’s Closure Compiler fork that supports a Source map during debug.
It doesn’t look like Google is going to popularize J2CL (compared to Flutter). I think they are OK with the current state. I can only assume they use it to support their legacy applications, I hope I’m wrong.
Three.js is migrating to ES6. It’s possible to use ES6 classes with J2CL but not in the case of three.js example classes, I hope devs will continue to keep backward compatibility with the pre-ES6 ecosystem.

TIP: Some time ago I ported Quake2 by id Software to J2CL using j2cl-maven-plugin with Quarkus backend, so you can take a look, it rocks!

P.S. It’s my very first article ever, so I'll be happy to hear what I could fix or improve.
P.P.S. The main question: Do we really need it all at all? If yes, I can publish it to Maven as a standalone library.