Analyse der Installation und des Setups des Google Web Toolkits für verschiedene Betriebssysteme

Inhaltsverzeichnis

1. Problem- und Aufgabenstellung

2. Einleitung
2.1. Motivation
2.2. Ziel

3. Grundlagen
3.1. Asynchronous JavaScript and XML
3.1.1. Der Begriff AJAX
3.1.2. Charakteristische Eigenschaften
3.2. Google Web Toolkit
3.2.1. GWT Java-to-JavaScript Compiler
3.2.2. Lifecycle und Execution Modes
3.2.3. GWT Tools
3.2.4. JavaScript Native Interface (JSNI)
3.2.5. Internationalisierung (I18N)
3.2.6. Asynchron durch Remote Procedure Calls
3.3. Entwicklungswerkzeuge – Integrated Development Environments (IDE)
3.3.1. Eclipse
3.3.2. IntelliJ IDEA

4. Praktischer Teil
4.1. Allgemeine Systemvorraussetzungen
4.2. Java
4.2.1. Installation des Java SDK unter Linux
4.2.2. PATH Umgebungsvariable
4.2.3. Installation des Java SDK unter Ubuntu
4.2.4. Installation des Java SDK unter Red Hat
4.2.5. Installation des Java SDK unter Debian
4.2.6. Installation des Java SDK unter Windows
4.3. Installation des GWT Frameworks
4.3.1. PATH Umgebungsvariable
4.3.2. Installation des GWT Frameworks unter Linux und Mac OS
4.3.3. Installation des GWT Frameworks unter Windows
4.4. Installation von Eclipse
4.5. Testen der Installation – Erste Schritte
4.5.1. Ausführen einer Beispielanwendung im Hosted und Web Mode
4.5.2. Erstellen eines einfachen GWT Beispieles

5. Diskussion

1. Problem- und Aufgabenstellung

Mit dem von Tim O’Reilly^[1] geprägten Begriff Web 2.0 [WEB01] sind Technologien und Konzepte wie Really Simple Syndication (RSS), Blogosphere, Google-Maps, Podcasting und Asynchronous JavaScript and XML (AJAX) verbunden.

Das Konzept AJAX ist am engsten mit dem Begriff Web 2.0 verknüpft, da durch die Verwendung von AJAX der Pagereload überflüssig und somit das Interaktionsverhalten durchgängiger wird. Darüber hinaus kann mit AJAX die Webseite Teilinformationen in Echtzeit erneuern, da mit AJAX nur Teilbereiche einer Seite neu geladen werden können und dadurch Polls in kurzer Zeit möglich sind.

AJAX Webapplikationen zu entwickeln ist allerdings komplex und auf Grund dieser Komplexität aufwendig. Mit dem Google Web Toolkit wird die Entwicklung von AJAX Anwendung vereinfacht und damit die Fehlerhäufigkeit verringert.

Im Rahmen dieser Bachelorarbeit sollen die Installationsverfahren und alle notwendigen Konfigurationsschritte untersucht werden, sowie eine Analyse der Möglichkeiten die das Google Web Toolkit bietet.

2. Einleitung

2.1. Motivation

Diese Arbeit ist die zweite Bachelorarbeit, die im Rahmen der exemplarischen Vertiefung des Bachelor-Studiums Informations- und Kommunikationssystem zu verfassen ist.

Auch diese Arbeit hat den Schwerpunkt „Web-Engeneering“ und wird sich mit dem Framework Google Web Toolkit (GWT) und im speziellen mit der Installation desselbigen und aller Notwendigen Komponenten, die für das Entwickeln von GWT-basierenden Webanwendungen erforderlich sind, auseinandersetzen.

Die genaue Ausarbeitung der Vorgehensweise während der Installation und die Strukturierung der einzelnen Schritte soll als Basis für das Kapitel über die Installation und Konfiguration eines Buches über das GWT verwendet werden.

2.2. Ziel

Um auf GWT basierende Webanwendungen entwickeln zu können benötigt man die Java Runtime Environment, das GWT selbst, eine Entwicklungsumgebung und einen Webserver.

Die vorliegende Arbeit wird zunächst die technologischen Grundlagen von AJAX, das Konzept und die Funktionsweisen des GWT und Entwicklungswerkzeuge für GWT vorstellen.

Im anschließenden praktischen Teil wird die Installation und Konfiguration des Java SDK und des Google Web Toolkit erarbeitet. Desweiteren wird nach erfolgreicher Installation und Konfiguration die Ausführung einer vom GWT mitgelieferten Beispielanwendung analysiert, um damit die erfolgreiche Implementierung aller Komponenten zu testen. Um das grundsätzliche Arbeiten mit dem GWT beschreiben zu können, wird anschließend ein einfaches Beispiel mit dem GWT implementiert, wobei die Architektur und die Funktionsweise erläutert wird.

Die Installation des GWT und aller erforderlichen Komponenten wird auf den Betriebssystemen Microsoft Windows XP, Microsoft Windows Vista, Linux und Apple Mac OS X durchgeführt.

Ob die Installation aufwendig ist und der Einstieg in die Entwicklung mit dem Google Web Toolkit sich komplex gestaltet, sind die Kernfragen, die diese Arbeit beantworten soll.

3. Grundlagen

In diesem Abschnitt werden die technologischen Grundlagen, die für das Verständnis von GWT und der Funktionsweise notwendig sind. Es wird zuerst das Konzept AJAX erklärt und die damit verbunden Technologien beschrieben, da dies für das Verstehen der späteren Abschnitte eine Vorraussetzung darstellt. Weiters werden die Kernkonzepte des GWT erläutert und die beiden Entwicklungswerkzeuge Eclipse und IDEA vorgestellt.

3.1. Asynchronous JavaScript and XML

“Ajax is a technology that complements Web 2.0 and the integration of many web

services at once.“ Gross, 2006 [AJAX02]

Das Konzept von AJAX ist wie schon erwähnt sehr eng mit dem Begriff Web 2.0 verbunden. Der Begriff Rich Internet Application (RIA) ist wiederum sehr eng mit AJAX verknüpft.

Nach Zanetti ist das Ziel einer RIA [AJAX01, S. 17] eine webbasierende Applikation bereitzustellen, jedoch sollte diese von den Funktionen und vom Look-and-Feel sich wie eine typische Fat-Client Applikation verhalten. Diese Applikationen sind dadurch benutzerfreundlicher und werden von den Internetbenutzern besser angenommen.

Dies bedeutet das mit dem Konzept von AJAX eine Web 2.0 RIA entwickelt werden kann.

In Abbildung 1 wird die graphische Darstellung der AJAX Architektur nach Gross [AJAX02, S. 11] gezeigt. Der Browser stellt dabei 2 unterschiedliche Inhalte dar, bezeichnet mit Content 1 und Content 2. Die Inhalte liegen auf verschiedenen Servern, wobei Content zwei wiederum auf 2 unterschiedliche Server verteilt ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: AJAX Architektur nach Gross, 2006 [AJAX02, S. 11]

3.1.1. Der Begriff AJAX

Gross [AJAX02] konkretisiert den Begriff AJAX:

- AJAX ist ein Akronym und die Verzweigungen sind vielschichtig
- Bei AJAX geht es nicht nur um Fat-Clients, JavaScript, XML oder asynchrones Verhalten, sondern vielmehr geht es darum Webapplikationen der nächsten Generation zu entwickeln.
- Verwendet man AJAX erzeugt man Webapplikationen, dies impliziert, dass Representational State Transfer (REST)^[2] verwendet wird, dies wiederum impliziert, dass HTML verwendet wird und dies impliziert, dass das Internet verwendet wird.

Der Begriff AJAX wurde jedoch von Jesse James Garrett von Adaptive Path in einem Artikel von 2005 eingeführt:

“Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.” Garrett, 2005 [AJAX04]

In diesem Artikel von 2005 erläutert Garrett [AJAX04] die mit AJAX verbundenen Technologien:

- auf Standards beruhende Präsentation - Verwendung von Extensible HyperText Markup Language (XHTML)^[3] und Cascading Style Sheets (CSS)
- Dynamische Anzeige und Interaktion durch Verwendung des Document Object Model
- Datenaustausch und Datenmanipulation durch Verwendung von XML und XSLT
- Asynchroner Datenaustausch durch XMLHttpRequest
- Verwendung von JavaScript, um alle Technologien zu vereinen

In der graphischen Darstellung in Abbildung 2 erklärt Garrett den Unterschied zwischen dem klassischen Webapplikationsmodel und dem AJAX Webapplikationsmodell.

Im klassischen Ansatz sendet zuerst der Client einen HTTP-Request an den Webserver. Dieser verarbeitet den Request, kontaktiert gegebenenfalls andere Legacy Systeme und sendet eine HTML Page an den Client zurück. Während der Verarbeitung auf Serverseite muss der User jedoch warten.

Im Gegensatz dazu lädt der Browser zu Beginn einer Session eine Ajax Engine. Diese ist Verantwortlich für das Rendern des Interfaces und für die Kommunikation mit dem Server. Diese Engine ermöglicht die asynchrone Kommunikation, wodurch auf der Clientseite eine durchgängige Interaktion mit der Applikation möglich wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Vergleich des traditionellem Webapplikationsmodell mit dem Ajax Webapplikationsmodell

In Abbildung 3 stellt Garrett [AJAX04] diesen Kommunikationsverlauf graphisch dar.

Im klassischen synchronen Web führt jede Clientinteraktion zur Übertragung von Daten vom Client zum Server, dieser verarbeitet diese und sendet anschließend seine Antwort zurück zum aufrufenden Client. Erst an dieser Stelle kann die nächste Userinteraktion stattfinden.

Im asynchronen Webapplikationsmodel hingegen wird deutlich, dass der Client in zwei Ebenen geteilt wird, in das Browser User Interface und die Ajax Engine. Jede Interaktion führt jetzt nicht mehr zum Übertragen von Daten zum Server, sondern zu einem Aufruf der Ajax Engine und einer sofortigen Antwort an das Browser User Interface. Die Ajax Engine kümmert sich nun um die den serverseitigen Aufruf. Nach Verarbeitung am Server und Erhalt der Antwort, verständigt die Ajax Engine das User Interface und erneuert somit die Daten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Das synchrone Interaktionsmodell des klassischen Webapplikationsmodells (oben) und das asynchrone Modell des Ajax Webapplikationsmodells (unten) [AJAX04]

3.1.2. Charakteristische Eigenschaften

Die charakteristischen Eigenschaften einer AJAX-Webapplikation sind nach Mahemoff [AJAX03] folgende:

- Durchgängiges Verhalten (Continous Feel) – Da bei Interaktion mit dem Server, dieser in Normalfall die gesamte Webseite neu laden muss, kommt es immer wieder zu Wartezeiten und Unterbrechungen. Mit Ajax soll wird der Pagereload überflüssig und das Interaktionsverhalten durchgängiger
- Real-Time Updates – Als Teil des Continous Feel können Ajax Applikationen die Webseite in Echtzeit erneuern. Da nur noch ein Teil der Applikation neu geladen werden kann, ist es damit möglich Polls in sehr kurzer Zeit zu senden, um Contentänderung neu übertragen zu können.
- Graphische Interaktion – Mit Ajax kann Drag and Drop realisiert werden
- Sprachenneutralität – Ajax kann mit jeder beliebigen Programmiersprache realisiert werden.

3.2. Google Web Toolkit

Das Google Web Toolkit ist ein Open Source^[4] Java Development Framework welches im Mai 2006 [GWT02] veröffentlicht wurde.

Als Teil der Google Code Initiative haben Bruce Johnson und Joel Webber das GWT entwickelt, um AJAX Anwendungen in Java leichter entwickeln zu können.

Die Problematik das die verschiedenen Webbrowser unterschiedliche Objektmodelle benutzen und die Unterschiede in den Leistungsmerkmalen gepaart mit der Verwendung von Java Script hat die Entwicklung von AJAX basierenden, komplexen Webanwendung bis jetzt sehr aufwendig gestaltet. Ziel bei der Entwicklung des GWT war es, das unterschiedliche Verhalten der Webbrowser in einen kohärenten Ansatz [GWT03] überzuführen.

Nach Bruce Johnson und Joel Webber^[5] sind die Kernkkonzepte des GWT

- GWT Java-to-JavaScript Compiler
- Hosted Mode
- JavaScript Native Interface (JSNI)

Im folgenden werden die Kernkonzepte, sowie Architekturkonzepte und Funktionsweisen näher beschrieben.

3.2.1. GWT Java-to-JavaScript Compiler

Eines der Schlüsselkonzepte des GWT ist Java to JavaScript Compiler, der sogenannte GWT Compiler. Die Funktionsweise des Compilers erläutert Hanson und Tacy [GWT04, S. 5] folgendermaßen:

„Das Kompilieren des Projektes erfolgt durch das Ausführen des Programms com.google.gwt.dev.GWTCompiler indem diesem die Location der Moduldefinitionsdatei als Parameter übergeben wird. Ein Modul wird dabei als Set von Java Klassen und Dateien, verbunden mit einer einzelnen Konfigurationsdatei, verstanden. Eine Moduldefinition enthält dabei einen Entry Point. Dieser Entry Point ist eine Javaklasse, welche beim Start des Programms zu allererst ausgeführt wird.“

Der GWT Kompiler arbeitet nicht auf die selbe Weise wie der Java Kompiler, da er nicht alles aus dem Modul kompiliert, sondern ausschließlich Elemente die für die Ausführung von Bedeutung sind. Dies hat den Vorteil, dass eine große Komponenten-Bibliothek entwickelt werden kann, ohne das diese jedes Mal vollständig mitkompiliert wird. Denn der GWT Kompiler kompiliert nur die Klassen und Methoden die gerade vom Entry Point gebraucht werden.

Im weiteren Verlauf beschreiben Hanson und Tacy [GWT04, S. 6] die Eigenschaften des GWT Kompilers:

„Der GWT Kompiler verfügt über mehrere Style-Modes, mit welchem das Ergebnis des JavaScript Codes beeinflusst werden kann. Der Default-Mode ist der sogenannte „Obfuscate“-Mode. Mit dieser Einstellung wird das Ergebnis des JavaScript Codes „Buchstabensuppe“ [GWT04, S. 6]. Dies bedeutet, dass der Code sehr optimiert und somit schwer zu lesen ist.“

Das Ziel dieser Einstellung ist es nicht, die Entwickler darin zu hindern, den Code zu lesen – obwohl dies eventuell als Vorteil angesehen werden könnte – sondern den resultierenden JavaScript Code so klein wie möglich zu halten. Bei sehr großen und komplexen Anwendung wird dieser Mode schlagend, da es sehr entscheidend ist wie viel Daten zum Client transferiert werden müssen.

Ein weiter Style-Mode ist der „Pretty“-Mode. Mit dieser Einstellung generiert der GWT Kompiler lesbaren Javascript Code.

Der dritte Style-Mode ist der „Detailed“-Mode. Mit diesem wird ebenfalls lesbarer Javascript Code wie mit dem „Pretty“-Mode generiert, nur enthält dieser die vollen Klassennamen in den Methodennamen, um den Javascript Code besser debuggen und ihn dem ursprünglichen Javacode zuordnen zu können.

Die beiden Betriebsarten „Pretty“ und „Detailed“ werden typischerweise nur während der Entwicklung verwendet, wobei der Mode „Obfuscate“ für die Produktivumgebung angewendet wird, um die Grösse der Dateien zu reduzieren.

Die folgende Gegenüberstellung einer vom GWT generierten Funktion nach dem kompilieren einer GWT Applikation in allen drei verfügbaren Modes soll zeigen, wie sich die Größe des Codes in den Modes Obfuscate, Pretty und Detailed verändert:

Obfuscate-Mode:

function r(){r = a;s = t('[N',[0],[10],[0],null);return window;}

Pretty-Mode:

function _$clinit(){

_$clinit = _nullMethod;

_NO_STACK_TRACE = _initDims('[N', [0], [10], [0], null);

return window;

}

Detailed-Mode:

function java_lang_Throwable_$clinit__(){

java_lang_Throwable_$clinit__ = nullMethod;

java_lang_Throwable_NO_1STACK_1TRACE = com_google_gwt_lang_Array_initDims__Ljava_lang_String_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2('[N', [0], [10], [0], null);

return window;

}

Nach Hanson und Tacy [GWT04, S. 6] ist ein wichtiger Aspekt des GWT Kompilers, dass dieser Java Source Code und nicht Java Binaries kompiliert. Dies hat zur Folge, dass die Sourcen aller benutzen Java Klassen verfügbar sein müssen. Dieser Umstand gewinnt dann an Bedeutung, wenn der GWT Code zur Wiederverwendung weitergegeben werden soll. Werden wieder verwendbare Jar Files generiert, müssen die eigentlichen Jar Files und die Java Source Files inkludiert werden.

Der Kompiler erwartet zusätzlich, dass der Source Code mit der Java 1.4 Syntax konform ist. Diese Java 1.4 Syntax Konformität wird eventuell in der Zukunft geändert, derzeit können allerdings keine Generics, Enums oder andere Java 1.5 Features verwendet werden. Diese Einschränkung gilt allerdings nur für Code, welcher in JavaScript Code konvertiert wird und nicht für die Entwicklung von Serverkomponenten, die mit dem Browser kommunizieren.

Bei der Kompilierung des Sourcecodes nach Javascript Code, wird dieser in ein einzelnes JavaScript File für jeden Browsertyp geschrieben. Dies bedeutet, dass vier sogenannte Cache Files erstellt werden. Jedes dieser vier Cache Files ist für einen spezifischen Browsertyp. Ein vom Browser gestartetes Bootskript wird das korrekte File beim Start der Applikation laden. Der Vorteil bei dieser Vorgehensweise ist, dass der vom Browser geladene Code keinen nichtausführbaren Code enthält.

Die Java Runtime Environment (JRE) Emulation Library ist ein Kernbestandteil des GWT. Wie schon bei der Funktionsweise des Kompilers erwähnt, muss, um auf der Clientseite auf eine Klasse zu referenzieren, auf den Java Source Code referenziert werden.

Bei Klassen von externen Bibliotheken – und somit auch bei Klassen der Java Runtime Environment selbst - verhält sich dies genauso. Um nun den Entwicklern die Möglichkeit zu geben JRE Klassen zu verwenden, stellt das GWT die JRE Emulation Library zur Verfügung. Diese Bibliothek hat die am häufigsten verwendeten JRE Klassen abgebildet und können für die Entwicklung verwendet werden. Diese werden im Kompilierungsschritt dann zu JavaScript umgewandelt.

Abbildung 4 und Abbildung 5 zeigen die verfügbaren Klassen der JRE Emulation Library:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Von der JRE Emulation Library unterstützte Klassen der java.lang JRE [GWT04]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Von der JRE Emulation Library unterstützte Klassen der java.util JRE [GWT04]

Die Verwendung der Klassen der Emulation Library unterscheidet sich gegenüber der Verwendung der original Klassen des JRE in einigen Punkten [GWT04, S. 7]:

- Double und Float sollten aus Performancegründen nicht als HashMap Keys verwendet werden
- Die regular Expressions unterscheiden sich für die Funktionen String.replaceAll, String.replaceFirst und String.split, da der Parameter als JavaScript regular Expression interpretiert wird.
- System.out und System.err sind zwar verfügbar, haben aber keine Bedeutung im Webmode
- Stack Traces in Throwable werden nicht unterstützt
- Die Implementierung der Vector Klasse besitzt nicht das Capacity und Growth Management der original Klasse, desweiteren wird der Index nicht validiert

3.2.2. Lifecycle und Execution Modes

Eine GWT Applikation kann in zwei Modes ausgeführt werden:

1. Hosted Mode
2. Web Mode

Hosted Mode

Der Hosted Mode ist eine vom GWT verwaltete Umgebung. In dieser Umgebung ist es möglich die Applikation zu testen und zu debuggen, da der Javacode nicht in JavaScript konvertiert wird, sondern in einer Java Virtual Machine ausgeführt wird.

In Abbildung 6 wird der typische Lifecycle einer GWT Applikationsentwicklung dargestellt, wobei dieser zeigt, dass fast das gesamte Testing und Debugging im Hosted Mode stattfindet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Typischer Lifecycle einer GWT Applikationsentwicklung [GWT04]

Features und Funktionsweisen des Hosted Mode:

- kann unter Windows, Linux und Mac OS X (ab Version Tiger 1.4) ausgeführt werden
- unter Windows wird als Hosted Browser der Internet Explorer verwendet, wogegen unter Linux ein Pre-Built Mozilla^[6] vom GWT Environment eingesetzt wird
- Java Code wird in nicht in JavaScript kompiliert, sondern nur interpretiert, dies ermöglicht die Debuggingfunktionalität der gewählten Entwicklungsumgebung zu verwenden

Starten einer Applikation im Hosted Mode

Mit dem GWT kann eine Applikation auf drei Arten im Hosted Mode [GWT06] gestartet werden:

1. Ausführen des applikationsspezifischen von GWT generierten Command-line Skriptes <Applikationsname>-shell.cmd
2. Ausführen des Command-line Skriptes aus der Eclipseumgebung
3. Starten des Hosted Modes direkt aus Eclipse

Wird die Applikation über das Command-line Skript gestartet, werden folgende Schritte durchgeführt:

1. Das Command-line Skript ruft die GWT Development Shell auf und übergibt dieser als Parameter den Klassennamen der Applikation.
2. Die GWT Development Shell startet nun die spezifische Applikation indem sie die Startseite in den vom GWT kontrollierten Browser lädt.
3. Anschließend ladet diese Startseite auf Grund des angeführten <script>-Tags das gwt.js Skript.
4. Das gwt.js Skript überprüft nun die Startseite analysiert den META-Tag <meta name=’gwt-module’>, um den Modulnamen der Applikation zu erfahren.
5. Ist der Name der Moduldatei bekannt liest das Skript die Moduldatei um den Namen der EntryPoint Klasse^[7] zu finden.
6. Nachdem der Name der EntryPoint Klasse herausgefunden wurde, wird die EntryPoint Klasse instanziert und die onModuleLoad() Methode ausgeführt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Startvorgang einer GWT Applikation im Hosted Mode

[...]

---

^[1] Tim O'Reilly (geb. 1954 in Cork, Irland) gilt als Erfinder des Web 2.0, seitdem er im Jahr 2004 eine gleichnamige Konferenz organisiert hatte.

^[2] REST ist ein Architekturstil für Hypermedia Systeme [REST01]

^[3] Standard des World Wide Web Consortiums – textbasierte Auszeichnungssprache

^[4] Open Source (engl.) Quelloffenheit ist ein Begriff der Open Source Initiative und wird in der Open Source Definition beschrieben.

^[5] Bruce Johnson und Joel Webber sind die Entwickler des Google Web Tool Kit

^[6] Mozilla ist der Begriff für Webbrowser, welche auf der Gecko-Rendering-Engine aufbauen

^[7] Die EntryPoint Klasse ist die erste Klasse deren Code ausgeführt wird.