J2CL - Besser spät als nie

    Niemand hat es geschafft, zu spät zur Beerdigung zu kommen.
    Valentin Domil


    Letzte Woche hat ein Team von Google den Quellcode für das J2CL-Framework veröffentlicht , über das seit 2015 gesprochen wurde. Die Idee, Java in JavaScript zu übersetzen, ist alles andere als neu und mit Google Web Toolkit ist längst jeder vollgestopft. Diese Community hat jedoch wie kein anderer auf dieses Produkt gewartet. Sie sprachen darüber und sprachen, aber niemand sah es.



        Es dauerte
    mehr als 3 Jahre seit der ersten Ankündigung und es scheint , dass das Produkt nicht einmal geboren , um den Markt verloren hat. Heute haben wir Scala.js , Kotlin.js und JSweet , ganz zu schweigen davon, dass die Webentwicklung von TypeScript erfasst wird und für Java kein Platz mehr vorhanden ist. In dieser Zeit haben viele, selbst die treuesten Javisten, das Vertrauen in Java für das Frontend verloren und dieses oder jenes JavaScript-Framework eingeschränkt.


    Da die Veröffentlichung stattgefunden hat, wollen wir sehen, was passiert ist und wem es nützlich sein könnte.


    Idee


    Grundsätzlich ist das Emulieren einer JVM in einem Browser eine schwierige Aufgabe. Die Entwickler von Google Web Toolkit haben sich lange dafür entschieden und einige Erfolge erzielt: Sie bauten einen Übersetzer, entwickelten Mechanismen zur Emulation der Standard-Java-Bibliothek und stellten ein Werkzeug für die Entwicklung von Anwendungen zur Verfügung.


    Dieser Ansatz hat viele Vorteile: statische Typisierung, die Möglichkeit, serverseitigen Code im Browser wiederzuverwenden, vorgefertigte Tools in Form einer Java-IDE. Viele Ansätze, die ursprünglich in GWT integriert wurden, sind jetzt in TypeScript, Web Pack und anderen Front-End-Entwicklungstools zu sehen.


    Das alte Google Web Toolkit war wegen seiner Schwerfälligkeit und seiner Abstraktion für die Erstellung von Benutzeroberflächen nicht beliebt. Die Idee von J2CL ist einfacher, Java zu möglichst geringen Kosten in JavaScript zu übersetzen, so dass Java leicht von JavaScript aus aufgerufen werden kann und umgekehrt.


    Und wenn es im fernen Jahr 2015 wirklich einen qualitativ hochwertigen Java-Übersetzer in JS gab, der nicht zu viel Müll enthält, ist nicht bekannt, wie sich die Webentwicklung weiterentwickeln würde.


    J2CL-Hintergrund


    Anfang 2015 traf das Google GWT-Team die schwierige, aber notwendige Entscheidung, ein neues Produkt zu entwickeln, mit dem Java in der Front-End-Entwicklung verwendet werden kann.


    Dies war vor allem 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 Bestandteil eines großen Stacks betrachteten. Dies erforderte eine völlig neue Vision und Erstellung von Werkzeugen von Grund auf, die eng mit dem restlichen Ökosystem verbunden sein sollten.


    Mit Hilfe von GWT war es fast unmöglich, diese Ziele zu erreichen. Obwohl GWT über Tools für die wechselseitige Interaktion mit JavaScipt verfügte, konnte das Framework kein großes Gepäck in Form einer Benutzeroberfläche, einer RPC-Bibliothek und anderer Anwendungs-APIs loswerden.


    Was ist das für ein Biest?


    Laut den Entwicklern ermöglicht J2CL die nahtlose Integration von Java-Code in JavaScript-Anwendungen. Es ist ein einfacher und einfacher Java-zu-JavaScript-Übersetzer mit Fokus auf Codeoptimierung mit Closure Compiler .


    • Sie können Java und JavaScript auf einfache Weise in einem Projekt kombinieren, um aus jeder der Sprachen das Beste herauszuholen.
    • Ermöglicht die Wiederverwendung von Code zwischen einer Serverlösung, einer Webanwendung und der Android-Plattform. Es gibt eine große Anzahl von Java-Bibliotheken, wie zum Beispiel: Guave, Dagger und AutoValue.
    • Modern und komfortabel. Erstellen Sie Projekte auf Basis von Bazel , unterstützt von Live-Reload.
    • Verifiziert Es wird argumentiert, 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 Java-Bytecode-Klassen zu verwenden. Dies bedeutet, dass Sie wie beim Google Web Toolkit zum Kompilieren des Projekts Quellcodes für alle verwendeten Bibliotheken benötigen. Darüber hinaus werden Fragen zur Unterstützung von Java-Funktionen in neuen Versionen gestellt. Momentan versprechen die Entwickler die Unterstützung aller syntaktischen Funktionen von Java 11.


    J2CL unterstützt keine GWT-Widgets, GWT-RPC und andere GWT-Bibliotheken - nur den grundlegenden Java- und JavaScript-Integrationsmechanismus - JSInterop .


    Ie Dies ist eine sehr eingeschränkte Version von GWT mit einem völlig neuen Transpiler. Und da das neue Produkt nicht mehr mit GWT kompatibel ist, wird es als J2CL und nicht als GWT bezeichnet. Daher ist die geplante Version von GWT 3 ein Framework auf J2CL, in dem alle Anwendungsbibliotheken von der Systemebene des Übersetzers getrennt werden.


    Bestehende Java-Kompatibilitätsbeschränkungen sind in GitHub beschrieben . Sie bleiben im Wesentlichen die gleichen wie in GWT - es gibt keine Unterstützung für Reflection, es gibt keine Java-Netzwerk-API. Etwas ist jedoch anders - die Semantik von Arrays und Listen wird nicht emuliert, der Index prüft beispielsweise nicht die Grenzen von Arrays. Die Entwickler konzentrieren sich nicht auf die Emulation des Verhaltens der JVM, sondern auf die Syntax der Sprache, um einen minimalen Aufwand zu gewährleisten und nicht tonnenweise JavaScript zu generieren, um vollständige Kompatibilität zu gewährleisten.


    Obwohl J2CL produktionsbereit ist, ist die OSS-Version davon noch weit entfernt. Beispielsweise gibt es Probleme beim Start von Projekten unter Windows und die Entwickler versprechen keine stabile API.


    Die Wahl von Bazel als Build-System für das interne Produkt von Google ist einfach zu erklären, aber für die Community gibt es keine Vorteile. Nun gibt es keine andere Möglichkeit, J2CL zu verwenden, um mehr über dieses Build-System zu erfahren. Es bleibt nur noch zu warten, bis die Community Plugins für Maven / Gradle schreibt.


    Wir versuchen es


    Um J2CL jetzt auszuprobieren, benötigen Sie Mac OS oder Linux.
    Zweitens müssen Sie Bazel installieren - ein etwas exotisches Build-System von Google.


    Nun können Sie zumindest etwas, zum Beispiel HelloWorld, aus dem offiziellen Repository sammeln .


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

    Wenn wir die Schlussfolgerung betrachten, 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!');

    Das beweist natürlich nichts, ist aber mit seinem Minimalismus nach den GWT-Modulen sehr erfreulich. Es gibt noch keine großen Anwendungsbeispiele, wir werden auf ihren Auftritt warten.


    Warum ist es notwendig, wenn xxx.js vorhanden ist?


    Die Antwort auf die Frage, warum es gefunden werden muss, ist schwierig. Auf den ersten Blick hat J2CL eine sehr starke Idee: Java für das Frontend auf dieselbe Art und Weise wiederverwenden, wie die Leute TypeScript verwenden. Andererseits scheint das Projekt zu spät gekommen zu sein.


    Neue Transporterprojekte in JS, wie Kotlin.js und Scala.js, werden als Plugins für Compiler implementiert und müssen den Quellcode nicht erneut analysieren. Und in dieser Hinsicht ist J2CL ein Schritt zurück, weil es den Quellcode benötigt, den es analysieren wird.


    Ein einzelner Punkt ist die Java-Sprache selbst. Warum in ausführlichem Java schreiben, wenn Sie sowohl den Server- als auch den Client-Teil in Kotlin schreiben können?


    Wenn ich jedoch mit einem anderen ähnlichen Projekt - JSweet - vergleiche , vertraue ich J2CL mehr. Tulsing von JSweet ist viel freundlicher und einsatzbereit, aber JSweet hat eine kleine Community und es ist fast alles von einer Person geschrieben.


    Code sprechen offen?


    Ich freue mich sehr, dass das Projekt eine offene Apache 2.0-Lizenz hat.


    Leider bedeutet Open Source keine Open Source-Entwicklung . Die größte Enttäuschung kam aus der aktuellen Situation in der Community. Das J2CL-Projekt wurde vor 3 Jahren angekündigt. Niemand zeigt jedoch den Quellcode. Es ist unmöglich, die endgültige API zu beeinflussen und den Entwicklungsprozess nicht zu beschleunigen, da keine Patches gesendet werden können.


    Hoffentlich wird sich die Situation verbessern und das Produkt wird lebensfähig.


    Update: Erste J2CL-Anwendung, die von GWT2 portiert wurde - https://github.com/DominoKit/dominodo


    Jetzt auch beliebt: