JavaScript fuer Eclipse-Entwickler

Ursachenbekämpfung; die Komplexität des Gesamtsystems steigt bei jedem hinzugefügten Framework. Der Betrieb, die Fehlersuche und die Wartung von Webanwendungen sind keine trivialen Tätigkeiten. Gerade die starken Technologiebrüche in der Laufzeitumgebung und in der Entwicklung sind in Bezug auf Effizienz und qualitätssichernde Maßnahmen aus dem Kapitel Software-Engineering absolut kontraproduktiv. Auch das Versprechen, das Problem durch noch bessere Tools in den Griff zu bekommen, ist nicht eingelöst geworden.
    Wie bei jeder Softwareentwicklung spielen die Erweiterungs- und Wartungskosten eine wesentliche Rolle im Lebenszyklus einer Webanwendung. Gesucht sind Methoden und Vorgehensweisen, die im Vorfeld zu besserer Softwarequalität führen, und Architekturmuster, die eine nachhaltige Wartung und Pflege der Webanwendungen begünstigen. Webanwendungen haben nicht selten die Anforderung, mit steigender Last entsprechend skalieren zu müssen. Technologien sollten das nicht verhindern. Sobald es sich nicht um eine Prototyp- oder eine Intranetanwendung für eine überschaubare Menge an Endanwendern handelt, sollte man sich kritisch mit dem Problem der Last und der Skalierbarkeit auseinandersetzen. Dabei müsste berücksichtigt werden, wie hoch der serverseitige Aufwand pro Sitzung ist. Während JSP und Servlets eine leichtgewichtige Laufzeitumgebung mit speicherpersistenten Servlets zur Verfügung stellen, tauchen die ersten Skalierungsprobleme schließlich mit weiteren einzusetzenden Technologien beziehungsweise Frameworks auf. Einerseits ist die Einführung von Komponentenmodellen in der Webentwicklung erstrebenswert, andererseits fordert die Transformation des Request-Response-Zyklus in ein ereignisbasiertes Modell auf dem Server ihren Tribut: einen mit der Anzahl der Teilnehmer steil steigenden Ressourcenverbrauch und eine relativ hohe Latenz. Modulare und komponentenbasierte Entwicklung hat in der Vergangenheit auch dazu geführt, dass im Browser benötigte CSS- und JavaScript-Ressourcen entsprechend der Komponentenstrukturierung auf viele kleine Dateien verteilt wurden. So bringt nicht selten jede UI-Komponente ihre eigenen CSS- und JavaScript-Ressourcen mit ins Boot. Das Ergebnis ist eine HTML-Seite, die viele Requests durch den HTTP Connection Bottleneck schicken muss.
    Durch den RIA-bedingten Architekturwechsel und den pfiffigen Compileransatz kann GWT diese Probleme während der Transformation lösen. Das Ergebnis: Latenzen werden nicht mehr in Sekunden, sondern in Millisekunden gemessen. Natürlich vorausgesetzt, der Server kann die RPC Calls entsprechend schnell ausliefern – die Webarchitektur steht einer skalierbaren, schnell reagierenden Anwendung nicht im Weg.

4.2 Der Ansatz
    Die Webentwicklung mit GWT unterscheidet sich beachtlich von den bisher üblichen Vorgehensweisen. Im Java-Umfeld haben sich zwei Arten der Entwicklung durchgesetzt: entweder IDE-basiert, zum Beispiel mit Eclipse WTP und Plug-ins, oder Build-Tool-basiert, zum Beispiel mit Maven. Gemeinsam haben die Vorgehensweisen den Fokus auf das Deployment und Redeployment der Anwendung, denn dynamische Webanwendungen in Java dürfen erst einmal paketiert und anschließend „deployt“ werden. Je nach Toolkette kann an der einen oder anderen Stelle optimiert beziehungsweise abgekürzt werden, das Grundprinzip bleibt aber gleich.
    Glücklicherweise können wir dank des „Java to JavaScript“-Ansatzes genau diejenigen Werkzeuge und Methoden auch für die Webentwicklung einsetzen, die wir seit Jahren für die Qualitätssicherung während der Java-Softwareentwicklung eingesetzt haben: Da GWT die Entwicklung der Webanwendung in der Programmiersprache Java ermöglicht, sind keine neuen Entwicklungsumgebungen nötig. Der Entwickler kann die bisher eingesetzte Java IDE weiterhin verwenden. Etablierte Konzepte, Vorgehensweisen und Werkzeuge können weiterhin beziehungsweise zum ersten Mal auch für die Webanwendungsentwicklung eigesetzt werden. PMD, FindBugs, Refactoring, etablierte Idiome und Entwurfsmuster, der GWT-Ansatz macht es möglich.
    Allerdings geht das Google-Team in Bezug auf den Entwicklungszyklus einen etwas anderen Weg. Da es sich bei GWT nicht um eine dynamische Java EE wie aus dem Lehrbuch handelt, sind auch Eclipse-Plug-ins aus dem Webumfeld kaum nützlich. So hat das Team ein eigenes Plug-in für Eclipse entwickelt, das eine nahtlose Integration der GWT-Entwicklung in Eclipse ermöglicht. Das Google Plug-in for Eclipse, kurz