Desktop Java

J2CL – Better late than never

Last week the Google team has finally published the source code of J2CL framework, which has been discussed since 2015. The idea of translating Java to JavaScript is not new at all, and everyone has had a hard time with Google Web Toolkit long before, yet this product was on the watch of the community like no other – it was discussed and became the topic of talks on conferences, but nobody’s seen it.

It’s been more than 3 years since the first announcement and it seems that the product lost its market even before its birth. Today we have Scala.js, Kotlin.js, and JSweet, and, besides, the development is already occupied by TypeScript and there’s no place for Java anymore. For such a long time even most devoted Java guys have lost their faith in “Java for Front end” and learned some JavaScript framework.

But since it is finally released, let’s have a look at the result and for what purposes it can be used.


Globally, emulating JVM in a browser is rather a complicated task. Google Web Toolkit developers have been trying to solve this problem for a long time and have achieved certain success: they built up a transpiler, developed standard Java library emulation mechanisms, provided the tooling for applications development.

Such an approach has many advantages: static type checking, reusability of a server code in a browser, ready-made tools represented by Java IDE. Many built-in approaches of GWT are now represented in TypeScript, Web Pack and other front-end development tools.

Good old Google Web Toolkit was taken against for being cumbersome and an abstract way of UI building. The idea of J2CL is simpler – it lets us translate Java to JavaScript with least possible overhead so that you could easily call Java from JavaScript and vice versa.

And even if in far 2015 there was a really good transpiler from Java to JS which would operate with no hash, it is nearly impossible to assume how would the web-development evolve then.

J2CL Prequel

At the beginning of 2015 Google GWT team took a hard, but urgent decision – to develop a new product enabling Java for front-end development.

Mainly it was due to the changes in the web-development trends and their new internal customers who considered Java for web not as an isolated ecosystem, but as an essential part of a large stack. It required a completely innovative point of view and creating the tools which should be closely integrated into the rest ecosystem from scratch.

With GWT it was almost impossible to achieve such aims. And though GWT had means of two-way interaction with JavaScipt, the framework couldn’t get rid of the great burden of UI, RPC library and other applied API.

What is that beast

As the developers claim, J2CL makes a seamless integration of Java code into JavaScript applications. It represents a simple and lightweight Java-to-JavaScript transpiler focused on the code optimization with the help of Closure Compiler.

    • It’s easy to mix Java and JavaScript in one project, getting the best of each language.
    • It lets reuse the code between the server solution, web-app and Android platform. Many Java libraries are available such as Guava, Dagger and AutoValue.
    • Modern and handy. The project build system is based on Bazel, Live-reload is supported.
    • Battle-proven. It’s claimed that J2CL is used in GSuite projects production: Gmail, Docs, Slides and Calendar.

In fact, J2CL translates source Java code to JavaScript code without Java classes bytecode. It means that, as it is in the case of Google Web Toolkit, all the used libraries sources are required for the project compilation. Besides, it raises the question of Java language capabilities supported in the latest releases. At this stage, the developers promise support of all syntax features of Java 11.

J2CL won’t support GWT Widgets, GWT RPC and other GWT libraries – only the basic Java and JavaScript integration tool – JSInterop.

I.e. this is quite a limited GWT version with a completely new transpiler. And since the new product is no longer compatible with GWT, it is called J2CL instead of GWT. On the whole, the upcoming GWT 3 release will represent a framework over J2CL where all the applicable libraries will be separated from the translator system level.

Existing Java compatibility constraints are described on GitHub. They are mainly the same as in GWT – there’s no reflection support, no network Java API. But there’s also something different – array and list semantics are not emulated, for example, checking if an index is within the array is not executed. The developers put highlight not on the JVM behavior emulation, but on the syntax means of language to minimize the overhead costs and avoid generating tons of JavaScript to ensure full compatibility.

Although J2CL is ready for production, its OSS version is far from it. For example, there are some problems with project start on Windows, and the developers can’t guarantee a stable API.

The choice of Bazel as a build system for an internal Google product is fair enough, but there are no advantages for the community in it and there’s no other way to use J2CL but to learn this build system. Meanwhile, we can only wait for the community to make plugins for Maven / Gradle.

Starting to work

First, J2CL requires Mac OS or Linux.

Second, you have to install Bazel – rather an exotic build system made by Google.

Now you can build some things, for example, HelloWorld from the official repository.

> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld

When you look at the output, you’ll be pleasantly surprised:

> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js
document.write('Hello from Java! and JS!');

Surely, it doesn’t prove anything, but it’s great to see such a minimalism after all GWT modules. There are no other application examples, so we’ll wait until they show up.

What it is for if we have xxx.js

For now, it is hard to tell what it is for. At first sight, J2CL comprises quite a bold idea – to reuse Java for front-end in the same way as TypeScript. On the other hand, the project seems to miss the boat.

New JS transpiler projects such as Kotlin.js and Scala.js are implemented as plugins for compilers and don’t require the source code parsing. From this point of view, J2CL is a step backward as it requires the sources to analyze.

One more questionable point is Java itself. Why use verbose Java when you can write both server and client side on laconic Kotlin?

However, comparing with another similar project – JSweet, I trust J2CL more. JSweet tooling is much friendlier and more usable, but JSweet community is rather small and it is almost entirely written by a single person.

So you say it’s open source?

It is definitely good news that the project is under Apache 2.0 free license.

Unfortunately, open source code is not the same as the open development process. The community’s greatest disappointment emerged because of the current situation, J2CL project was announced 3 years ago, but no one has shown its source code, you can’t influence its final API or speed up the development process because there’s nowhere to send hotfixes.

Let’s hope the situation will change for the best and the product will go live.

Published on Java Code Geeks with permission by Yuriy Artamonov, partner at our JCG program. See the original article here: J2CL – Better late than never

Opinions expressed by Java Code Geeks contributors are their own.

Want to know how to develop your skillset to become a Java Rockstar?

Join our newsletter to start rocking!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button