Bisher konnte noch niemand zu spät zu ihrer Beerdigung kommen.
Valentin Domil
Letzte Woche hat ein Team von Google endlich den Quellcode für das J2CL-Framework veröffentlicht , über das seit 2015 gesprochen wird. Die Idee, Java in JavaScript zu übersetzen, ist alles andere als neu, und alle haben lange Zeit mit dem Google Web Toolkit gefüllt, aber die Community hat wie kein anderes auf dieses Produkt gewartet - sie haben darüber gesprochen und Reden gehalten, aber niemand hat es gesehen.
Seit der ersten Ankündigung sind mehr als drei Jahre vergangen, und es scheint, dass das Produkt den Markt verloren hat, ohne überhaupt geboren zu werden. Heute haben wir Scala.js , Kotlin.js und JSweet , ganz zu schweigen davon, dass die Webentwicklung von TypeScript entführt wurde und kein Platz mehr für Java vorhanden ist. In dieser Zeit haben viele, selbst die engagiertesten Javisten, das Vertrauen in „Java for Front-End“ verloren und dieses oder jenes JavaScript-Framework eingeschränkt.
Mal sehen, was passiert ist und wem es nützlich sein könnte, seit die Veröffentlichung stattgefunden hat.
Idee
Grundsätzlich ist das Emulieren von JVMs in einem Browser eine schwierige Aufgabe. Die Entwickler des Google Web Toolkit haben es seit langem gelöst und bestimmte Erfolge erzielt: Sie haben einen Übersetzer erstellt, Emulationsmechanismen für die Standard-Java-Bibliothek entwickelt und die Anwendungsentwicklung optimiert.
Dieser Ansatz bietet viele Vorteile: statische Typisierung, die Möglichkeit, Servercode in einem Browser wiederzuverwenden, und vorgefertigte Tools in Form einer Java-IDE. Viele der ursprünglich in GWT festgelegten Ansätze sind jetzt in TypeScript, Web Pack und anderen Front-End-Entwicklungstools zu sehen.
Das alte Google Web Toolkit wurde wegen seiner Sperrigkeit und seiner Abstraktion zum Erstellen einer Benutzeroberfläche nicht gemocht. Die Idee von J2CL ist einfacher: Sie können Java zu möglichst geringen Kosten in JavaScript übersetzen, sodass Sie Java problemlos über JavaScript aufrufen können und umgekehrt.
Und wenn es 2015 wirklich einen hochwertigen Java-Übersetzer in JS ohne unnötigen Müll gegeben hätte, ist nicht bekannt, wie sich die Webentwicklung weiterentwickeln würde.
Hintergrund J2CL
Anfang 2015 traf das Google GWT-Team eine schwierige, aber notwendige Entscheidung - ein neues Produkt zu entwickeln, mit dem Sie Java in der Front-End-Entwicklung verwenden können.
Dies war hauptsächlich auf die sich ändernden Trends in der Webentwicklung und ihre neuen internen Kunden zurückzuführen, die Java für das Web nicht als isoliertes Ökosystem, sondern als integralen Bestandteil eines großen Stacks betrachteten. Dies erforderte eine völlig neue Vision und die Schaffung von Werkzeugen von Grund auf neu, die eng in den Rest des Ökosystems integriert werden sollten.
Mit GWT war es fast unmöglich, diese Ziele zu erreichen. Obwohl es im GWT Tools für die bidirektionale Interaktion mit JavaScipt gab, konnte das Framework nicht viel Gepäck in Form einer Benutzeroberfläche, einer RPC-Bibliothek und anderer Anwendungs-APIs entfernen.
Was ist das für ein Biest?
Laut den Entwicklern bietet J2CL eine nahtlose Integration von Java-Code in JavaScript-Anwendungen. Es ist ein einfacher und leichter Java-zu-JavaScript-Übersetzer mit Schwerpunkt auf Codeoptimierung mit dem Closure Compiler .
- Sie können Java und JavaScript problemlos in einem Projekt mischen und so das Beste aus jeder Sprache herausholen.
- Ermöglicht die Wiederverwendung von Code zwischen einer Serverlösung, einer Webanwendung und der Android-Plattform. Eine große Anzahl von Java-Bibliotheken ist verfügbar, z. B. Guava, Dagger und AutoValue.
- Modern und komfortabel. Die Zusammenstellung von Projekten basiert auf Bazel , das von Live-reload unterstützt wird.
- Verifiziert. Es wird behauptet, dass J2CL in der Produktion in GSuite-Projekten verwendet wird: GMail, Docs, Slides und Calendar.
Im Wesentlichen übersetzt J2CL Java-Quellcode in JavaScript-Code, ohne den Bytecode der Java-Klasse zu verwenden. Dies bedeutet, dass wie im Fall des Google Web Toolkit der Quellcode für alle verwendeten Bibliotheken zum Kompilieren des Projekts benötigt wird. Darüber hinaus wirft dies Fragen zur Unterstützung der Java-Sprachfunktionen in neuen Versionen auf. Derzeit versprechen Entwickler Unterstützung für alle Syntaxfunktionen von Java 11.
J2CL unterstützt keine GWT-Widgets, GWT RPC und andere GWT-Bibliotheken - nur grundlegendes Java und den JavaScript-Integrationsmechanismus JSInterop .
Das heißt, Dies ist eine sehr begrenzte Version von GWT mit einem völlig neuen Transporter. Und da das neue Produkt nicht mehr mit GWT kompatibel ist, heißt es nicht GWT, sondern J2CL. Infolgedessen wird die geplante Version von GWT 3 ein Framework über J2CL sein, in dem alle Anwendungsbibliotheken von der Systemebene des Übersetzers selbst getrennt werden.
Bestehende Java-Kompatibilitätsbeschränkungen werden auf GitHub beschrieben . Grundsätzlich blieben sie dieselben wie in GWT - es gibt keine Reflexionsunterstützung, keine Java-Netzwerk-API. Aber etwas ist anders - die Semantik von Arrays und Listen wird nicht emuliert, zum Beispiel prüft der Index nicht auf Vorkommen innerhalb der Grenzen von Arrays. Entwickler konzentrieren sich nicht auf die Emulation des JVM-Verhaltens, sondern auf die Syntax der Sprache, um einen minimalen Overhead zu gewährleisten und nicht Tonnen von JavaScript zu generieren, um die vollständige Kompatibilität sicherzustellen.
Obwohl J2CL für die Produktion bereit ist, ist seine OSS-Version noch weit davon entfernt. Beispielsweise gibt es Probleme beim Starten von Projekten unter Windows, und Entwickler versprechen keine stabile API.
Die Wahl von Bazel als Build-System für das interne Produkt von Google ist leicht zu erklären, aber es gibt keine Vorteile für die Community und es gibt keine andere Möglichkeit, J2CL zu verwenden, als dieses Build-System zu erlernen. Alles was bleibt ist zu warten, bis die Community Plugins für Maven / Gradle geschrieben hat.
Versuchen Sie es
Um J2CL jetzt zu testen, benötigen Sie zunächst Mac OS oder Linux.
Zweitens müssen Sie Bazel installieren - ein etwas exotisches Build-System von Google.
Jetzt können Sie zumindest etwas, beispielsweise HelloWorld, aus dem offiziellen Repository sammeln .
> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld
Wenn wir uns die Schlussfolgerung ansehen, werden wir angenehm überrascht sein:
> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js document.write('Hello from Java! and JS!');
Dies beweist natürlich nichts, ist aber sehr zufrieden mit seinem Minimalismus nach den GWT-Modulen. Es gibt noch keine guten Anwendungsbeispiele, wir werden auf ihr Erscheinen warten.
Warum ist es notwendig, wenn es xxx.js gibt?
Die Antwort auf die Frage, warum dies gefunden werden muss, ist immer noch schwierig. Auf den ersten Blick hat J2CL eine sehr starke Idee - Java für das Frontend wiederzuverwenden, genau wie Leute, die TypeScript verwenden. Auf der anderen Seite scheint das Projekt zu spät zu sein.
Neuere Transporterprojekte in JS wie Kotlin.js und Scala.js werden als Compiler-Plugins implementiert und müssen den Quellcode nicht erneut analysieren. In dieser Hinsicht ist J2CL ein Schritt zurück, da es den Quellcode benötigt, den es analysieren wird.
Ein separater Punkt ist die Java-Sprache selbst. Warum in ausführlichem Java schreiben, wenn Sie sowohl den Server- als auch den Client-Teil in prägnantem Kotlin schreiben können?
Obwohl ich im Vergleich zu einem anderen ähnlichen Projekt - JSweet - J2CL mehr vertraue. JSweet-Tools sind viel freundlicher und benutzerfreundlicher, aber JSweet hat eine kleine Community und wird fast ausschließlich von einer Person geschrieben.
Sagen Sie Open Source Code?
Ich freue mich sehr, dass das Projekt eine offene Lizenz für Apache 2.0 hat.
Open Source bedeutet leider keinen offenen Entwicklungsprozess . Die größte Enttäuschung der Community kam von der aktuellen Situation. Das J2CL-Projekt wurde vor 3 Jahren angekündigt. Niemand zeigt jedoch den Quellcode. Sie können die endgültige API nicht beeinflussen und den Entwicklungsprozess nicht beschleunigen, da keine Patches gesendet werden können.
Hoffen wir, dass sich die Situation verbessert und das Produkt lebensfähig wird.
Update: Erste von GWT2 portierte J2CL-Anwendung - https://github.com/DominoKit/dominodo