J2CL - Better Late Than Never

No one has managed to be late for their funeral.
Valentin Domil

Last week, a team from Google finally posted the source code for the J2CL framework , which was talked about since 2015. The idea of ​​translating Java into JavaScript is far from new, and everyone has long been crammed with Google Web Toolkit, but this product was waiting for the community like no other - they spoke about it and made speeches, but no one saw it.

More than 3 years have passed since the first announcement, and it seems that the product has lost the market without even being born. Today we have Scala.js , Kotlin.js and JSweet , not to mention that web development is captured by TypeScript and there is no space left for Java. During this time, many, even the most faithful javists, have lost faith in “Java for the Front-end” and curbed this or that JavaScript framework.

Since the release did happen, let's see what happened and to whom it might be useful.

Idea

Fundamentally, emulating a JVM in a browser is a difficult task. For a long time, the developers of the Google Web Toolkit decided on it and achieved some success: they built a translator, developed mechanisms for emulating the standard Java library, and provided a tool for developing applications.

There are many advantages to this approach: static typing, the ability to reuse server-side code in the browser, ready-made tools in the form of a Java IDE. Many approaches that were originally incorporated into GWT are now seen in TypeScript, Web Pack, and other front-end development tools.

The old Google Web Toolkit was disliked for its cumbersomeness and its abstraction for building UI. The idea of ​​J2CL is simpler to allow Java to be translated into JavaScript at the lowest possible cost, so that Java can be easily invoked from JavaScript and vice versa.

And if, in the distant 2015, there really existed a high-quality Java translator in JS without too much rubbish, then it is not known how web development would develop further.

J2CL Background

In early 2015, the Google GWT team made the difficult but necessary decision to develop a new product that allows Java to be used in front-end development.

This was mainly due to the changing trends in web development and their new internal customers, who viewed Java for the web not as an isolated ecosystem, but as an integral part of a large stack. This required a completely new vision and creation of tools from scratch, which should be closely integrated with the rest of the ecosystem.

With the help of GWT, it was almost impossible to achieve these goals. And although GWT had tools for two-way interaction with JavaScipt, the framework could not get rid of large baggage in the form of a UI, RPC library, and other application APIs.

What kind of beast is it

According to the developers , J2CL provides seamless integration of Java code in JavaScript applications. It is a simple and lightweight Java to JavaScript translator with an emphasis on code optimization with Closure Compiler .

• You can easily mix Java and JavaScript in one project, getting the best from each of the languages.
• Allows you to reuse code between a server solution, a web application and the Android platform. A large number of Java libraries are available, such as: Guava, Dagger and AutoValue.
• Modern and comfortable. Build projects built on the basis of Bazel , supported by Live-reload.
• Verified. It is claimed that J2CL is used in production in GSuite projects: GMail, Docs, Slides and Calendar.

Essentially, J2CL translates Java source code into JavaScript code without using Java bytecode classes. This means that, as in the case of Google Web Toolkit, to compile the project, you need source codes for all used libraries. In addition, it raises questions about the support of Java language features in new releases. At the moment, the developers promise support for all the syntactic features of Java 11.

J2CL will not support GWT Widgets, GWT RPC and other GWT libraries - only basic Java and JavaScript integration mechanism - JSInterop .

Those. This is a very limited version of GWT with a completely new transpiler. And since the new product is no longer compatible with GWT, it is called J2CL, not GWT. As a result, the planned release of GWT 3 will be a framework over J2CL, where all application libraries will be separated from the system level of the translator itself.

Existing Java compatibility limitations are described on GitHub . Basically, they remain the same as in GWT - there is no support for reflection, there is no Java network API. But something is different - the semantics of arrays and lists is not emulated, for example, the index entry in the array boundaries is not checked. The developers are not focusing on emulating the behavior of the JVM, but on the syntax of the language to ensure minimal overhead and not generate tons of JavaScript to ensure full compatibility.

Although J2CL is ready for production, its OSS version is still far from that. For example, there are problems with the start of projects on Windows and the developers do not promise a stable API.

Choosing Bazel as a build system for Google’s internal product is easy to explain, but for the community there are no advantages to it, and now there’s no other way to use J2CL to learn about this build system. While it remains only to wait for the community to write plugins for Maven / Gradle.

We try

First of all, in order to try J2CL now, you need Mac OS or Linux.
Secondly, you need to install Bazel - a somewhat exotic build system from Google.

Now you can at least collect something, for example, HelloWorld from the official repository.

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

If we look at the conclusion, we will be pleasantly surprised:

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

This, of course, proves nothing, but is very pleased with its minimalism after the GWT modules. There are no large examples of applications yet, we will wait for their appearance.

Why is this needed if there is xxx.js

The answer to the question why it needs to be found is difficult. At first glance, J2CL has a very strong idea - to reuse Java for the frontend in the same way that people use TypeScript. On the other hand, it seems that the project was late.

New transporter projects in JS, such as Kotlin.js and Scala.js, are implemented as compiler plugins and do not need to re-parse the source code. And in this regard, J2CL is a step back, because it needs the source code that it will parse.

A single point is the Java language itself. Why write in verbose Java, if you can write both the server and the client part on concise Kotlin?

Although, if compared with another similar project - JSweet , then I trust J2CL more. Tulsing from JSweet is much more friendly and ready to use, but JSweet has a small community and it is almost all written by one person.

Code speak open?

Certainly pleased that the project has an open Apache 2.0 license.

Unfortunately, open source does not mean open source development at all . The biggest disappointment came in the community from the current situation, the J2CL project was announced 3 years ago, but no one shows its source code, it is impossible to affect its final API and not to speed up the development process, because there is no place to send patches.

Hopefully, the situation will get better and the product will become viable.

Update: first J2CL application ported from GWT2 - https://github.com/DominoKit/dominodo