No one has ever been late to their own funeral.
Valentine Domil
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.
Idea
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 on 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.