Das GWT-Toolkit: Erstellen Sie leistungsstarke JavaScript-Frontends mit Java

Das GWT Web Toolkit, früher bekannt als Google Web Toolkit, ist eine Reihe von Entwicklungstools zum Erstellen und Optimieren komplexer browserbasierter Anwendungen unter Verwendung der Programmiersprache Java.

Was GWT nicht zu „noch einem weiteren Java-Tool zum Schreiben von Web-Apps“ macht, ist die Tatsache, dass das Herzstück des Toolkits ein Compiler ist, der Java in JavaScript (sowie HTML und CSS) umwandelt und es Entwicklern ermöglicht, Front-End-Webanwendungen zu schreiben und gleichzeitig alle Stärken von Java nutzen.

Es ist sogar einfach, eine Mischung aus Java und JavaScript zu verwenden, da GWT eine robuste Interoperabilitätsarchitektur für die Anbindung an die Webplattform enthält. Ähnlich wie das Java Native Interface (JNI) es der Java Virtual Machine (JVM) ermöglicht, plattformspezifische Routinen aufzurufen (z. B. um auf bestimmte Hardwarefunktionen zuzugreifen oder externe Bibliotheken aus anderen Sprachen zu verwenden), ermöglicht uns GWT, den größten Teil einer Anwendung in Java und dann, falls erforderlich, eine bestimmte Web-API zu verwenden oder vorhandene JavaScript-Bibliotheken zu nutzen, um „nativ“ zu werden und in JavaScript zu springen.

GWT wurde als Google-Produkt geboren, ging aber Ende 2011 auf Open Source über und wird heute unter der Apache-Lizenz (Version 2) unter dem Namen GWT Open Source Project veröffentlicht. Es wird von einem Lenkungsausschuss mit Vertretern mehrerer Unternehmen, darunter Google, RedHat, ArcBees, Vaadin und Sencha, sowie unabhängigen Entwicklern aus der Community verwaltet.

GWT in der Vergangenheit und in der Zukunft

Das Google Web Toolkit wurde erstmals im Jahr 2006 veröffentlicht. Es wurde als Tool entwickelt, um Google-Ingenieuren bei der Entwicklung ihrer komplexen browserbasierten Anwendungen wie AdWords, Google Wallet und Google Flights zu helfen, und wird seit kurzem im Mittelpunkt von verwendet Google Sheets und Inbox-Anwendungen.

Im Jahr 2006 waren Browser (und JavaScript-Interpreter) alles andere als standardisiert. Der Front-End-Code war langsam, fehlerhaft und schwer zuverlässig zu verwenden. Es fehlte fast vollständig an qualitativ hochwertigen Bibliotheken und Frameworks für die Webentwicklung. Zum Beispiel gab es jQuery bis zu diesem Jahr gar nicht. Um umfangreiche Webanwendungen entwickeln zu können, entschieden sich die Ingenieure von Google daher, vorhandene Tools und Kompetenzen zu nutzen. Java war die am besten geeignete Sprache für ihre Bedürfnisse, da sie bekannt und perfekt in IDEs wie Eclipse integriert war, und so begann das Google Web Toolkit sein Leben.

Das Ziel war mehr oder weniger, die Unterschiede zwischen Browsern zu verbergen und die Tricks zu kapseln, die zum Schreiben von effizientem JavaScript in einem Java-Compiler erforderlich sind, um die Entwickler von der Tyrannei der Browser-Techniken zu befreien.

Natürlich hat sich das Web in den letzten zehn Jahren verändert; Browser sind schneller geworden und haben sich auf Implementierungsstandards konvergiert, und es wurden viele großartige Frontend-Frameworks und -Bibliotheken entwickelt, darunter jQuery, Angular, Polymer und React. Die erste Frage, die Sie sich natürlich stellen könnten, lautet also: „Ist GWT noch nützlich?“

Mit einem Wort: Ja .

Im Kontext der modernen Webentwicklung ist das Targeting von Browsern unvermeidlich und JavaScript ist zur Lingua Franca von Frontend-Anwendungen geworden. Aber natürlich sind unterschiedliche Tools und Sprachen für unterschiedliche Aufgaben besser geeignet. GWT und eine Handvoll ähnlicher Projekte zielen darauf ab, Browser anzusprechen, ohne Entwickler auf die Verwendung von JavaScript zu beschränken.

Die Entwicklung und der Einsatz von „compile-to-the-web“-Werkzeugen wie GWT wird in naher Zukunft durch die sogenannte WebAssembly-Gruppe des World Wide Web Consortium erleichtert. Es gibt nicht nur viel Platz für Tools, die zu JavaScript kompilieren, sondern dieser Ansatz kann auch einen echten Bedarf in Kontexten decken, die von der Auslagerung eines Teils der Berechnung an Browser, der Wiederverwendung von vorhandenem Code und Bibliotheken bis hin zur gemeinsamen Nutzung von Code zwischen Back-End und Front-End reichen , Nutzung bestehender Kompetenzen und Workflows und Nutzung von Funktionen verschiedener Sprachen (z. B. statische Typisierung im Fall von GWT).

Das GWT-Projekt wird voraussichtlich bald Version 2.8 veröffentlichen, und Version 3.0 befindet sich in der Entwicklung, wobei große Verbesserungen in Arbeit sind:

• neu erfundene Interoperabilität mit JavaScript
• verbesserter (fast vollständig neu geschriebener) Compiler
• Modernste Java-Unterstützung (z. B. Lambdas)

Tatsächlich sind die meisten Funktionen von GWT 3.0 bereits im öffentlichen Git-Repository verfügbar. Schauen Sie sich einfach den Trunk hier an und kompilieren Sie GWT gemäß der Dokumentation hier.

Die GWT-Community

Seit GWT 2011 Open Source wurde, hat die Community eine zentrale Rolle in der Entwicklung des Projekts übernommen.

Die gesamte Entwicklung findet im Git-Repository statt, das auf gwt.googlesource.com gehostet wird, und alle Codeüberprüfungen werden auf gwt-review.googlesource.com durchgeführt. Auf diesen Seiten kann jeder, der an der Entwicklung des Toolkits interessiert ist, einen Beitrag leisten und sehen, woran die Community arbeitet. In den letzten Jahren ist der Anteil neuer Patches von Nicht-Googlern von etwa 5 Prozent im Jahr 2012 auf etwa 25 Prozent im letzten Jahr gestiegen, was die wachsende Beteiligung bestätigt.

In diesem Jahr hat sich die Community zu einigen großen Meetings in den USA und Europa zusammengefunden. Die von Vaadin organisierte GWT.create fand im Januar sowohl in München, Deutschland, als auch in Mountain View, Kalifornien, statt und zählte mehr als 600 Teilnehmer aus Dutzenden von Ländern. Am 11. November werden wir in Florenz, Italien, die zweite Ausgabe der GWTcon veranstalten, einer von der Gemeinschaft betriebenen GWT-Konferenz, bei deren Organisation ich behilflich bin.

Wofür ist GWT geeignet?

Eine jährliche Umfrage zum GWT-Toolkit, die von Vaadin veröffentlicht wird, erörtert die Entwicklungsentwicklung von GWT, die Meinung der Entwickler zum Toolkit, das Gute, das Schlechte und so weiter. Diese Umfrage lässt uns auch verstehen, wofür das Toolkit verwendet wird, wie sich die Benutzergemeinschaft verändert und welche Erwartungen Entwickler an die Zukunft des Toolkits haben.

Der Future of GWT Report für 2015 ist hier zu finden und macht deutlich, dass GWT sehr beliebt ist, um umfangreiche Webanwendungen zu erstellen. Auf Seite 14 heißt es beispielsweise: „Die meisten Anwendungen sind Geschäftsanwendungen, die datenintensiv sind und mit denen viele Stunden am Tag gearbeitet wird.“

Wie zu erwarten ist, lässt sich leicht schlussfolgern, dass das natürliche Umfeld für GWT der Bereich der großen Webanwendungen ist, wo die Wartbarkeit des Codes wichtig ist und große Teams von der Struktur der Java-Sprache profitieren.

Betrachtet man hingegen die Benchmarks für von GWT generierten Code (z. B. in der Keynote der letztjährigen GWT.create-Konferenz auf den Seiten 7, 8 und 11), ist dies in Bezug auf Leistung und Leistung leicht zu erkennen Codegröße ist das kompilierte JavaScript umwerfend großartig. Bei richtiger Anwendung ist die erzielte Leistung vergleichbar mit dem besten handgeschriebenen JavaScript. Dadurch ist es tatsächlich möglich, GWT einzusetzen, um Java-Bibliotheken ins Web zu portieren.

Dies beleuchtet ein weiteres ideales Szenario für GWT. Das Java-Ökosystem ist voll von hochwertigen Bibliotheken, die kein gebrauchsfertiges Gegenstück in JavaScript haben. Der GWT-Compiler kann verwendet werden, um solche Bibliotheken für das Web anzupassen. Mit anderen Worten, mit GWT können wir Bibliotheken mischen, die sowohl in Java als auch in JavaScript verfügbar sind, und sie im Browser ausführen.

Dieser Ansatz zeigt sich in der Entwicklung von PicShare, wo wir zeigen, wie mehrere Java-Bibliotheken, die nicht allgemein für das Web in Betracht gezogen werden (z. B. NyARToolkit), mithilfe von GWT auf den Browser portiert und mit Web-APIs, einschließlich WebRTC und WebGL, kombiniert werden können erhalten Sie ein vollständig webbasiertes Augmented-Reality-Tool. Ich war stolz darauf, PicShare letzten Januar auf der GWT.create-Konferenz 2015 vorzustellen.

Unter der Haube: Java in JavaScript umwandeln

Das GWT-Toolkit ist ein mäßig komplexer Satz von Tools, aber dank einer überraschend benutzerfreundlichen Integration mit Eclipse kann jeder im Handumdrehen damit beginnen.

Das Erstellen einer einfachen Anwendung mit GWT ist für jeden mit einem Hintergrund in Java-Entwicklungsprojekten relativ einfach. Aber um zu verstehen, was „wirklich passiert“, lohnt es sich, die Hauptkomponenten des Toolkits zu analysieren:

• Java-zu-JavaScript-Transpiler
• Emulierte Java-Laufzeitumgebung
• Interoperabilitätsschicht

Der optimierende Compiler von GWT

Eine ausführliche Beschreibung der Funktionsweise des Compilers wird ziemlich früh sehr technisch, und wir müssen nicht so tief graben, aber einige der allgemeinen Konzepte sind einen Blick wert.

Das erste, was Sie verstehen müssen, ist, dass GWT Java durch Übersetzung auf Quellcodeebene in JavaScript kompiliert. Das heißt, der Java-Quelltext wird in JavaScript übersetzt ( transpiled ist der Fachausdruck). Dies steht im Gegensatz zu einer Art Java Virtual Machine, die in JavaScript geschrieben ist und Java-Bytecode ausführt. (Dies ist tatsächlich möglich und wird von Doppio verwendet, aber so funktioniert GWT nicht.)

Stattdessen wird der Java-Code in einen abstrakten Syntaxbaum (AST) zerlegt, der die syntaktischen Elemente des Codes darstellt. Es wird dann einem äquivalenten (und optimierten) Javascript-AST zugeordnet, das schließlich wieder in den tatsächlichen JavaScript-Code konvertiert wird.

Das Abwägen der Vor- und Nachteile der Transpilation ist weit entfernt von dem Gegenstand dieses Beitrags, aber lassen Sie mich anmerken, dass GWT mit dieser Methode die Garbage-Collection-Dienste des JavaScript-Interpreters zusammen mit allen anderen nativen Funktionen des Browsers direkt nutzen kann.

Natürlich gibt es einige knifflige Stellen. Beispielsweise hat JavaScript nur einen numerischen Typ, der den 64-Bit- long -Integer-Typ von Java nicht enthalten kann, daher erfordern long Typen eine besondere Behandlung durch den Compiler. Darüber hinaus hat die statische Java-Typisierung in JavaScript keine direkte Bedeutung, daher muss besonders darauf geachtet werden, dass beispielsweise Typumwandlungsoperationen nach der Transpilation äquivalent bleiben.

Andererseits besteht ein leicht zu schätzender Vorteil der Transpilation darin, dass GWT Optimierungen (sowohl hinsichtlich Größe als auch Leistung) auf Java-Ebene und auf JavaScript-Ebene durchführen kann. Der resultierende Standard-JavaScript-Code kann sogar in Ihrer Deployment-Pipeline weiterverarbeitet werden. Eine gängige Praxis, die jetzt in die Standard-GWT-Distribution integriert wurde, besteht beispielsweise darin, die JavaScript-Ausgabe des Transpilers mit dem hochspezialisierten JavaScript-to-JavaScript Closure Compiler (ein weiteres Geschenk der Google-Götter) zu optimieren.

Die ausführlichste Beschreibung des GWT-Compilers, die ich kenne, finden Sie in diesem Slide-Deck und dem ursprünglichen Vortrag, aus dem es stammt. Hier finden Sie Details zu anderen coolen Funktionen des Kompilierungsprozesses, wie z. B. die Fähigkeit von GWT, Code aufzuteilen und mehrere separate Skriptdateien zu generieren, die unabhängig vom Browser geladen werden.

Die emulierte JRE

Der Java-zu-JavaScript-Compiler wäre kaum mehr als eine Neuheit, wenn er nicht durch eine Implementierung der Java Runtime Environment (JRE) ergänzt würde, die die Kernbibliotheken bereitstellt, auf die sich fast jede Java-Anwendung stützt. Grob gesagt wäre das Arbeiten in Java beispielsweise ohne Collections- oder String-Methoden frustrierend, und natürlich ist das Portieren dieser Bibliotheken eine titanische Arbeit. GWT füllt diese Lücke mit dem sogenannten Emulated JRE.

Die emulierte JRE ist keineswegs eine vollständige Neuimplementierung der Java JRE, sondern vielmehr eine Art Auswahl von Klassen und Methoden, die auf Client-Seite nützlich (und verwendbar) sein können. Die Funktionalitäten, die in der Java JRE enthalten sind, die Sie jedoch nicht in der emulierten JRE finden, lassen sich in drei Kategorien einteilen:

• Dinge, die nicht clientseitig portiert werden können. Beispielsweise können java.lang.Thread oder java.io.File nicht in einem Browser mit derselben Semantik wie Java implementiert werden. Die Browserseite ist Single-Threaded und hat keinen direkten Zugriff auf das Dateisystem.

• Dinge, die implementiert werden könnten, aber in Bezug auf Codegröße, Leistung oder Abhängigkeiten „zu viel kosten“ würden und die die Community daher lieber nicht innerhalb von GWT haben möchte. Zu dieser Kategorie gehört beispielsweise die Java-Reflektion ( java.lang.reflect ), die erfordern würde, dass der Transpiler Klasseninformationen für jeden Typ speichert, und dies würde dazu führen, dass die Größe des kompilierten JavaScripts ansteigt.

• Dinge, die niemanden interessierten und deshalb nicht umgesetzt wurden.

Wenn die emulierte JRE nicht Ihren Anforderungen entspricht (z. B. wenn Sie eine Klasse benötigen, die nicht bereitgestellt wird), ermöglicht Ihnen GWT, Ihre eigene Implementierung zu schreiben. Dieser leistungsstarke Mechanismus, der über das Tag <super-source> verfügbar ist, ermöglicht es, Probleme bei der Anpassung neuer externer Bibliotheken zu umgehen, die Teile der JRE verwenden, die nicht emuliert wurden.

Es kann übermäßig komplex oder sogar unmöglich sein, eine vollständige Implementierung einiger Teile der JRE bereitzustellen, sodass Ihre eigenen Implementierungen für bestimmte Aufgaben möglicherweise nicht strikt der Semantik der JRE von Java folgen, obwohl sie in Ihrem speziellen Fall funktionieren. Wenn Sie erwägen, Ihre Klassen an das Projekt zurückzugeben, denken Sie daran, dass es für die emulierte JRE von größter Bedeutung ist, dass jede enthaltene Klasse genau der gleichen Semantik der ursprünglichen Java-JRE folgt. Dadurch wird sichergestellt, dass jeder Java-Code in JavaScript neu kompilieren und darauf vertrauen kann, dass er die erwarteten Ergebnisse erhält. Stellen Sie immer sicher, dass Ihr Code gründlich getestet wurde, bevor Sie ihn an die Community zurückgeben.

Interoperabilitätsschicht

Um ein effektives Werkzeug für die Produktion realer Webanwendungen zu sein, muss GWT es Entwicklern ermöglichen, einfach mit der zugrunde liegenden Plattform zu interagieren. Das heißt, der Browser und das DOM.

Von Anfang an wurde GWT entwickelt, um eine solche Interaktion über das JavaScript Native Interface (JSNI) zu unterstützen, was den Zugriff auf In-Browser-APIs zum Kinderspiel macht. Beispielsweise können Sie unter Verwendung von Syntaxfunktionen, die für den GWT-Compiler einzigartig sind, den folgenden Java-Code schreiben:

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

und es steht Ihnen frei, den Hauptteil der Methode in JavaScript zu implementieren. Sie können sogar JavaScript-Objekte in ein JavaScriptObject (JSO) einschließen und es in Ihrem Java-Code zugänglich machen.

Ein Beispiel dafür, wo diese Schicht ins Spiel kommt, findet sich im Kontext der UI-Komposition. Mainstream-Java hat schon immer das Standard-Widgets-Toolkit verwendet, um UI-Elemente zu erstellen, wobei das Java Native Interface genutzt wurde, um auf die Fenster- und Eingabesysteme des zugrunde liegenden Betriebssystems zuzugreifen. Die Interoperabilitätsschicht von GWT tut dasselbe, sodass herkömmliche Widgets nahtlos im Browser funktionieren. Der einzige Unterschied besteht darin, dass in diesem Fall das zugrunde liegende System der Browser und das DOM sind.

Native Front-End-Frameworks haben sich jedoch in den letzten Jahren schnell verbessert und bieten heute erhebliche Vorteile gegenüber den Widgets von GWT. Mit zunehmender Ausgereiftheit dieser Frameworks haben Versuche, sie im JSNI zu implementieren, Mängel in der Architektur der Interoperabilitätsschicht aufgedeckt. Ab Version 2.7 hat GWT JsInterop eingeführt, einen neuen Ansatz auf Basis von Java-Annotationen, mit dem Sie Ihre GWT-Klassen schnell und einfach mit JavaScript integrieren können. Es ist nicht mehr notwendig, JSNI-Methoden oder JSO-Klassen zu schreiben. Stattdessen können Sie einfach Annotationen wie @JSType oder @JSProperty , sodass Sie mit nativen JavaScript-Klassen arbeiten können, als wären sie Java.

Die vollständige Spezifikation von JsInterop ist noch in Arbeit, und die neuesten Updates können nur ausprobiert werden, indem der Quellcode aus dem GWT-Repository kompiliert wird. Aber es ist bereits klar, dass dies die neue Richtung ist, die es GWT ermöglichen wird, mit den sich entwickelnden Webplattformen Schritt zu halten.

Ein laufendes Projekt, das JsInterop nutzt, ist das kürzlich veröffentlichte gwt-polymer-elements, das alle Eisen- und Papierelemente von Polymer für GWT verfügbar macht. Interessant an dieser Bibliothek ist, dass die Entwickler die Java-API nicht von Hand generieren müssen. Das Projekt verwendet gwt-api-generator, um die meisten Schnittstellen direkt zu generieren, indem es die Polymer-Bibliothek und die JSDoc-Anmerkungen analysiert. Dies macht es einfach, die Bindungen auf dem neuesten Stand zu halten.

Letzte Worte

Mit den Verbesserungen des Compilers, der Interoperabilitätsebene und der Leistung und Größe des generierten Codes in den letzten zwei Jahren ist klar, dass GWT nicht nur „ein weiteres Webentwicklungstool“ ist, sondern auf dem besten Weg ist, ein wichtiges Referenz-Toolkit für zu werden die Entwicklung umfangreicher, komplexer Webanwendungen und könnte sogar eine ausgezeichnete Wahl sein, um einfachere Apps großartig zu machen.

Ich verwende GWT täglich in meiner Arbeit als Entwickler und Berater, aber vor allem liebe ich GWT, weil es mir ermöglicht, die Grenzen der Browserfähigkeiten zu erweitern und zu zeigen, dass moderne Webanwendungen so leistungsfähig sein können wie Desktopanwendungen.

Die Community des GWT-Projekts ist wirklich aktiv, und es werden ständig neue Bibliotheken, Projekte und Anwendungen vorgeschlagen, die auf GWT basieren. In Florenz findet am 11. November die von der Community betriebene GWTcon2015 statt. Wenn Sie in der Region sind, hoffe ich, dass Sie kommen und einige der Kernentwickler treffen und mehr über alle Möglichkeiten erfahren, Teil der Entwicklung dieses erstaunlichen Toolkits zu sein.