Die Community atmet auf

GWT 2.5 – Technische Evolution und ein wichtiges Signal

Ferdinand Schneider
©Shutterstock/Sergey Nivens

Das aktuelle Release des Google Web Toolkits liefert neben der Einführung einiger teilweise noch als experimentell eingestufter Features vor allem Verbesserungen am Herzstück der Plattform, dem Java-nach-JavaScript-Crosscompiler. Doch allein die Veröffentlichung einer neuen Version lässt die Community aufhorchen…

History and Present…

Das Google Web Toolkit (GWT) ermöglicht auf einzigartige Weise die ingenieursmäßige Entwicklung komplexer Webapplikationen, indem der Sourcecode in Java geschrieben und dann von einem Crosscompiler direkt in eine vollwertige AJAX-Anwendung übersetzt wird.

Nach dem Release 2.4 im September 2011 wurde es ruhig um GWT. Spekulationen über die Aufgabe der Plattform zugunsten Googles neuer Web-Programmiersprache Dart machten im Netz die Runde. Viele Unternehmen, die inzwischen große Investitionen in ihre GWT-Anwendungslandschaft getätigt hatten, bekamen deutlich zu spüren, dass GWT kein vollständig offenes Projekt, sondern von den Planungen des US-Konzerns abhängig war, der selbst viele seiner Anwendungen auf Basis von GWT entwickelt hatte.

Auf der Hausmesse Google I/O im Juni 2012 kam dann der Befreiungsschlag. Ray Cromwell, Technical Lead bei Google, verkündete neben der Vorstellung des neuen GWT Release 2.5 die Gründung eines Steering Committee, dem die Verantwortung für die zukünftige Entwicklung der Plattform übertragen wurde [1]. Gleichzeitig soll eine stärkere Einbindung der Community erfolgen. Damit haben Unternehmen zum ersten Mal die Möglichkeit, die weitere Entwicklung von GWT maßgeblich zu beeinflussen.

Die neue Offenheit zeigte sich erstmals, als das Steering Committee eine Umfrage unter Entwicklern startete und eine „Wishlist“ für die Plattform zusammenstellte [2], [3]. Ganz oben auf der Liste der meistersehnten Features waren unter anderem Performanceverbesserungen am Compiler sowie eine effizientere Entwicklungsumgebung. Mit Version 2.5 wird vielen dieser Wünsche Rechnung getragen und gleichzeitig Googles Botschaft von der I/O-Konferenz untermauert: GWT ist am Leben und hat noch eine lange Zukunft vor sich.

Performance-Verbesserungen

Bekanntermaßen ist die Startup-Performance der generierten AJAX-Anwendungen stets eine Herausforderung in der GWT-Entwicklung. Der initiale Pageload einer Applikation ist in der Regel sehr groß, da die gesamte Anwendungslogik inklusive aller Benutzeroberflächen bereits beim Start geladen wird. Genau hier wurden in GWT 2.5 große Fortschritte erzielt. Durch Optimierungen ist es gelungen, die Größe des generierten AJAX-Codes signifikant zu senken. In einem Experiment, bei dem verschiedene Anwendungen jeweils mit GWT 2.4 und 2.5 kompiliert wurden, konnte allein durch den Wechsel des Compilers eine Verringerung des generierten JavaScript-Outputs um ca. fünf Prozent erreicht werden. Als Beispiele kamen die beiden öffentlich verfügbaren GWT-Projekte DynaTableRF und Showcase zum Einsatz. Die Betrachtung weiterer Real-Life-Projekte zeigt, dass mit steigender Komplexität der Anwendungen der Effizienzgewinn noch größer ausfällt und bis zu 20 Prozent beträgt.

Doch das genügt den GWT-Entwicklern nicht. In 2.5 haben sie den JavaScript-Compiler aus dem Closure-Toolkit von Google in GWT integriert [4]. Der Closure-Compiler optimiert bestehenden JavaScript-Code durch eine Reihe von Maßnahmen wie bspw. die Reduktion von Funktionen und das Entfernen toten Codes. In der bereits bekannten Teststellung wird durch den Closure-Compiler eine weitere Reduzierung des generierten JavaScripts um sechs (Showcase) bis acht (DynaTableRF) Prozent erreicht. Abbildung 1 veranschaulicht die Verbesserungen bei der Größe des Compiler-Outputs in einem Diagramm.

Abbildung 1: Größe des vom GWT-Compiler generierten Javascripts in Kilobyte

Trotzdem sollte man den Einsatz des Closure-Compilers mit Vorsicht genießen, da sich die Kompilierungszeit bei Aktivierung der entsprechenden Compileroption eklatant um bis zu 150 Prozent verlängert.

Mit der neuen Version von GWT wurde neben der Anwendungsgröße auch an der Laufzeiteffizienz geschraubt. Durch Fragement Merging wird das Nachladen von Code in einer Anwendung zur Compilezeit optimiert. Bislang entsteht beim Einsatz von Splitpoints zur Modularisierung des generierten JavaScripts ein großes Leftover Fragment, welches den von Fragmenten gemeinsam genutzten Code enthält (siehe Abbildung 2). Sobald der erste Splitpoint in einer Anwendung erreicht ist, muss das komplette Leftover Fragment mit geladen werden.

Abbildung 2: Bisheriger Umgang mit gemeinsam genutzten Code in Fragmenten

GWT 2.5 optimiert diesen Prozess durch das Fragment Merging. Der Compiler erkennt, welcher Code gemeinsam von welchen Fragmenten genutzt wird, und fasst diese, wie in Abbildung 3 veranschaulicht, inklusive des gemeinsam genutzten Codes zu einem neuen Fragment zusammen.

Abbildung 3: Leeres Leftover Fragment durch Fragment Merging

Das Leftover Fragment wird bei dieser Vorgehensweise auf ein Minimum reduziert, wodurch die Ladezeit für gemeinsam genutzten Code besser auf alle asynchronen Funktionsaufrufe verteilt wird.

Super Dev Mode

Der bislang für die GWT-Entwicklung zum Einsatz kommende Development Mode hat einige strukturelle Schwächen. Das Konzept basiert auf Browser-Plug-ins, die den Java-Code quasi direkt im Browser ausführen, statt die Anwendung in JavaScript zu übersetzen. Für den Entwicklungsmodus wäre eine auf Standardtechnologien basierende Lösung, welche die Dev Mode Plug-ins überflüssig macht, wesentlich eleganter. Mit Source Maps existiert seit Kurzem eine solche Spezifikation. Source Maps ermöglichen dem Browser das Mapping von ausgeführtem JavaScript auf andere Source-Dateien als die, die gerade tatsächlich geladen sind.

Basierend auf dieser Technologie haben die GWT-Entwickler in 2.5 einen neuen Entwicklungsmodus integriert, den Super Dev Mode. Dieser folgt einem völlig anderen Konzept als der bekannte Dev Mode, da er die Anwendung „under development“ tatsächlich in JavaScript übersetzt. Dies macht ein Browser Plug-in überflüssig, da nun schon während der Entwicklung eine vollwertige AJAX-Anwendung vorliegt! Um den Code dennoch debuggen zu können, kommen Source Maps zum Einsatz, die es ermöglichen, den Java-Code mit den Entwicklungstools des jeweiligen Browsers zu debuggen. Abbildung 4 zeigt dies anhand eines einfachen Beispiels.

Abbildung 4: Der neue Super Dev Mode ermöglicht das Debuggen der Java Sourcen direkt im Browser

Leider ist der Super Dev Mode derzeit noch hochexperimentell und damit weit von einem produktiv einsetzbaren Stadium entfernt. Wer das neue Entwicklungswerkzeug trotzdem ausprobieren möchte, sollte sich auf viel Ausprobieren gefasst machen. Bereits das korrekte Einrichten und Starten des Tools erfordert einiges an Einstellungen, und die sehr dürftige Dokumentation im GWT Development Guide [5] ist hier nur selten eine Hilfe. Wohl nicht umsonst wünschen die Entwickler dem interessierten Leser zum Abschluss der Super-Dev-Mode-Dokumentation „Happy hacking!“

Neue Features

Die zeitliche Spanne, mit der neue Features aus der Web-Welt  in GWT zur Verfügung stehen, kann zukünftig durch das neue, derzeit noch experimentelle Elemental API drastisch verkürzt werden. Hierbei handelt es sich um ein komplett neues API mit eigener Typ-Hierarchie, das direkt aus dem JavaScript-Standard [6] generiert ist. Die Entwicklung mit GWT fühlt sich damit fast an wie „echte“ JavaScript-Programmierung.

Im folgenden Beispiel wird mittels Elemental das HTML5 File API, welches einen besseren Zugriff auf das Dateisystem des Clients ermöglicht, verwendet. Bislang wäre dies in GWT nur über den Einsatz nativer JavaScript-Methoden möglich gewesen. Die Beispielanwendung soll die Auswahl beliebig vieler Dateien auf dem Dateisystem des Clients durch den Benutzer ermöglichen und deren Eigenschaften wie Name, Dateityp und –größe in einer Liste ausgeben [7].

public void onModuleLoad() {
	// Creates the following HTML snippet:
	// <input type="file" name="files[]" multiple />
	// <output id="list"></output>
	final InputElement filesElement = 
getDocument().createInputElement();
	final OutputElement outputElement = 
getDocument().createOutputElement();

	filesElement.setType("file");
	filesElement.setMultiple(true);
	filesElement.setName("files[]");

	Element body = getDocument().getBody();
	body.appendChild(filesElement);
	body.appendChild(outputElement);
}

Zunächst erstellen wir in Listing 1 die für unseren Versuchsaufbau nötige Oberfläche. Hier sieht man sehr deutlich die Nähe zur JavaScript-Programmierung. Die Methoden und Typen sind 1:1 übernommen, und die Manipulation des DOMs erfolgt wie in JavaScript durch Metaprogrammierung von HTML direkt in der Anwendungslogik.

filesElement.addEventListener(Event.CHANGE, new EventListener() {
	@Override
	public void handleEvent(Event evt) {
		// get the file list
		FileList files = ((InputElement) evt.getTarget()).getFiles();

		// list some properties
		ArrayOf<String> output = Collections.arrayOf();
		for (int i = 0; i < files.length(); i++) {
			File f = files.item(i);

			String type = f.getType().isEmpty() ? "n/a" : f.getType();
			String ouputString = "<li><strong>" + f.getName()
					+ "</strong> (" + type + ") - " + f.getSize()
					+ " bytes</li>";

			output.push(ouputString);
		}
		
		//insert into output element
		outputElement.setInnerHTML("<ul>" + output.join("") + 


In Listing 2 wird ein Eventhandler an unserem Input-Element registriert. Dieser holt sich zunächst die Liste der vom Benutzer ausgewählten Dateien und schreibt daraufhin für jede Datei einen Eintrag in die Output-Liste. Ruft man die so entwickelte Anwendung im Browser auf und wählt einige Dateien im File-Dialog aus, wird die in Abbildung 5 dargestellte Ausgabe erzeugt.

Abbildung 5: File-API Beispiel mit Elemental

Bislang werden in GWT eigene Cells auf Basis von HTML-Schnipseln, die dann von GWT an der entsprechenden Stelle im Cell-Widget eingefügt werden, implementiert. Die Entwicklung eigener Controls auf Basis der Konkatenation von HTML-Code ist sehr umständlich und fehleranfällig. GWT 2.5 bietet eine neue Möglichkeit zur Entwicklung von Cells auf Basis des UiBinders. Die Cells werden dabei wie von anderen Widgets vor GWT 2.5 bereits bekannt in einer XML-Datei via HTML-Templates beschrieben und können dann in Java über einen UiRenderer angesprochen werden. Listing 3 und 4 zeigen ein sehr einfaches Beispiel auf Basis des neuen API.

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'>
	<ui:with field='name' type='java.lang.String' />

	<div ui:field="divElement">
		Hallo <ui:text from='{name}' />.
	</div>
</ui:UiBinder>

public class HalloWeltCell extends AbstractCell<String> {
	interface HalloWeltUiRenderer extends UiRenderer {
		void render(SafeHtmlBuilder sb, String name);
		DivElement getDivElement(Element parent);
	}

	private static HalloWeltUiRenderer renderer = GWT
			.create(HalloWeltUiRenderer.class);

	@Override
	public void render(Context c, String value, SafeHtmlBuilder sb) {
		renderer.render(sb, value);
	}
}

Dieser Mechanismus vereinfacht die Entwicklung eigener Cell-Typen enorm und schafft endlich mehr Durchgängigkeit bei der Entwicklung von Oberflächen mit dem UiBinder.

Weitere neue Features von GWT sind ein verbessertes API zur Accessibility, das sich noch mehr am ARIA-Standard für Barrierefreiheit orientiert, sowie neue experimentelle Basistypen für hochperformante Controls, die zukünftig die Rendering-Time signifikant verringern und somit die Performance komplexer Widgets verbessern sollen.

… and the Future…

Mit GWT 2.5 wurden viele Wünsche der Community angegangen und eine Preview auf kommende Key-Features wie bspw. den Super Dev Mode und das Elemental API gegeben. Durch die Initiierung solcher umfangreicher Innovationen beweist das GWT-Entwicklungsteam um Google, dass das Projekt alles andere als tot ist und in nächster Zeit wieder volle Fahrt aufnehmen wird. Auf der Google I/O 2013 wurde erstmals eine offizielle Roadmap vorgestellt, die die inhaltliche Fokussierung bei der Weiterentwicklung von GWT in den nächsten Jahren festlegt [8]. Mit den kommenden Releases kann sich die Community demnach unter anderem über mehr Offenheit des Frameworks, Performanceverbesserungen sowie Mobile als Schlüsselthema freuen. Sollte dieser Kurs der Offenheit und Anwenderorientierung beibehalten werden, wird GWT in Zukunft wohl noch mehr an Bedeutung gewinnen und den Entwicklern auch weiterhin viel Freude bereiten.

Aufmacherbild: DNA molecule is located in front of a colored background von Shutterstock / Urheberrecht: Sergey Nivens

Geschrieben von
Ferdinand Schneider
Ferdinand Schneider
Ferdinand Schneider ist Software Engineer bei der Schwäbisch Hall Kreditservice AG in Baden-Württemberg. Er ist im Java-Ökosystem zu Hause und beschäftigt sich seit einiger Zeit intensiv mit dem Google Web Toolkit, durch das er wieder Spaß an der Webentwicklung gefunden hat.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.