GWT: Google Web Toolkit

Sie zeigen erstmal zwei Beispiele: Eine E-Mail-Anwendung und eine Bilderverwaltung. Ist alles schnell und reaktiv a la Desktop-Anwendung - AJAX eben.

Verschiedbbare Popup-Dialoge sind möglich. Drag&Drop wird per Default nicht unterstützt. Man kann es aber trotzdem bauen - ist in den Beispielen auch drin.

Jetzt kommen die GWT-Konzepte.

GWT folgt dem "Avant-garde"-Ansatz. Das bedeutet, dass man fast ausschließlich in Java programmiert. Dazu wird der Java-Client-Code nach JavaScript, HTML und CSS "compiliert". (Fragt mich nicht, warum der Ansatz "Avant-garde" heißt.)

GWT stellt eine Reihe von UI-Komponenten bereit und AJAX-Support. Zusätzlich enthält das GWT einen Java-To-JavaScript-Compiler. Für den Client-Code darf man nur JDK 1.4 verwenden und Teile aus java.lang und java.util. Mit der Hosted Mode Shell kann man in Eclipse debuggen.

Jetzt wird ein Hello-World-Beispiel programmiert. Mit der Hosted-Remote-Shell kann man die Anwendung gefakt ausführen. Dann werden die Benutzeraktionen mit Default-JavaScript abgefangen und direkt an die Java-Klasse umgeleitet. So kann man das auch leicht testen und debuggen.

Wie jetzt so eine Java-Klasse aus? Man holt sich ein Element aus dem DOM einer Tenplate-Seite und fügt dort UI-Komponenten ein (RootPanel.get("xxx").add(button)). An den Elementen registriert man Listener a la Swing. Wenn man mehrere Elemente hinzufügen will, braucht man Layout-Manager, die sehr an Swing erinnern. Da scheint mir ein Bruch zu sein, weil man das Layout eigentlich ja über CSS machen will.

Sieht ja soweit ganz einfach aus. GWT scheint einiges an Abstraktion über HTML/HTTP zu legen, ähnlich JSF. Wie viele Probleme das in der Praxis macht, ist eine interessante Frage.

Zum Thema Browser: Das GWT verbirgt die Browser-Inkompatibilitäten.

Jetzt werden die Elemente des GWT vorgestellt. Neben den Standards gibt es Menüs, Tabs, Trees, Popup-Dialoage. Eigenes Widgets kann man in Java selbst erstellen.

Der Aufruf vom Client an den Server wird als Remote-Procedure-Call angeboten. Nachrichten werden im JSON-Format und nicht als XML verschickt. Man muss ein Subinterface von RemoteService definieren, dass der Client aufrufen muss. Und dann muss man ein eigenes Servlet als Subklasse eines GWT-Servlets bauen. Die Folie ist zu schnell weg, so dass mir nicht ganz klar ist, wie das Servlet aussehen muss.

Auf Basis des Interfaces erzeugt GWT einen Proxy, der dann an das Servlet delegiert. Sieht dem EJB-Konzept ähnlich.

Wenn man selbstdefinierte Klassen an der RPC-Schnittstelle verwenden will, müssen die nach JSON serialisierbar sein. Dazu muss man wohl nur ein spezielles Marker(?)-Interface implementieren.

Dummerweise ist AJAX asynchron und das schlägt bis auf das RPC-Interface durch.

Mit JSNI (JavaScript Native Interface) kann man Client-Java mit JavaScript integrieren. So kann man z.B. reine Web-Widget-Libs von Drittherstellern verwenden.

Es gibt natürlich eine Integration mit Spring. Dazu braucht man die GWT Widget Library. Deren Verwendung ist dringend empfohlen, auch weil das GWT doch nicht alle Eigenartigkeiten des IE verbirgt. Das holt das GWT Web Toolkit nach.

Fazit der Referenten:
* Man muss keien JavaScript programmieren. JavaScript ist so mächtig und flexibel, dass viele Entwickler überfordert sein werden.
* Browser-Eigenheiten werden eingekapselt.
* Man könnte auch AJAX-Frameworks a la Dojo oder Prototype verwenden. Das ist ein eigenes Look&Feel angeblich schwer zu bauen.
* DWR (Dynamic Web Remoting) wäre noch eine Alternative. Dort programmiert man den Client in JavaScript und den Server in Java.
* OpenLaszlo ist sehr mächtig, aber man braucht ein Flash-Plugin.
* XUL geht auch nur, wenn der Browser XUL unterstützt.
* GWT funktioniert bei einfachen Sachen ganz einfach. Man muss aber doch viele Eigenheiten des GWT erst erlernen.
* GWT kapselt die Browser-Eigentheiten bzgl. JavaScript weg, aber nicht bzgl. Rendering und CSS.
* Google verwendet GWT bisher gar nicht selbst. ("Google doesn't eat its own dog food!")
* Java 5 geht in GWT (noch) nicht, so dass man für Client- und Server-Java doch wieder unterschiedliche Compiler und Sprachfeatures hat.
* Es gibt in GWT kein MVC-Framework. Da muss man sich selbst was ausdenken.
* Es gibt viele Widgets. Die gehen deutlich über HTML-Forms hinaus, kommen aber nicht ganz an andere Web-Widget-Libs heran.
* GWT ist natürlich Open-Source.
* Es gibt eine große GWT-Community und gute Doku.
* Bei einfachen Web-Anwendungen sollte man GWT nicht verwenden. GWT ist nur interessant, wenn man Desktop-artige Software braucht.

Java-To-JavaScript-Compiler wirkt auf mich wie Rocket-Science. Das ist beeindruckend und auch ein wenig unheimlich. Wenn da mal was nicht funktioniert...

P.S.: Die Referenten haben irgendein cooles Tool, mit dem man Markierungen auf den Bildschirm malen kann - und das unter Windows! Das ist nützlich, wenn man was außerhalb von Powerpoint zeigen will - z.B. Code in Eclipse.

P.P.S.: Wenn man mit dem eigentlichen Inhalt des Vortrags fertig ist, ist nicht der geeignete Zeitpunkt, um seine Firma vorzustellen. Dann gehen die Leute nämlich raus :-)