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.
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.
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
- 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.
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.
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.