J2CL - Better Late Than Never
No one has managed to be late for their funeral.
Since the release did happen, let's see what happened and to whom it might be useful.
Fundamentally, emulating a JVM in a browser is a difficult task. For a long time, the developers of 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.
And if, in the distant 2015, there really was a high-quality Java translator in JS without too much rubbish, then it is not known how web development would develop further.
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
- 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 argued that J2CL is used in production in GSuite projects: GMail, Docs, Slides and Calendar.
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 on top of J2CL, where all application libraries will be separated from the system level of the translator itself.
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.
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 gratifying with its minimalism after the GWT modules. There are no big examples of applications yet, we will wait for their appearance.
Why is it necessary 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 plugins for compilers and they 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