GWT 2.7 bringt mit dem Super Development Mode neues Debugging

Debuggen im Browser mit GWT 2.7

Holger Herrmann
debugging-browser

© Shutterstock / JMiks

Mit Veröffentlichung von GWT 2.7 wurde der bisher verwendete Development Mode, früher auch „Hosted Mode“ oder „Jetty Mode“, als „deprecated“ (veraltet) gekennzeichnet. Bei vielen Entwicklern löste schon die Ankündigung Bedenken oder sogar Ängste aus: „Mit dem Super Development Mode (SDM) kann ich doch nur noch im Browser debuggen – wie soll das gehen?“

Seit November 2014 ist GWT 2.7 nun verfügbar, weshalb wir uns mit der Frage beschäftigt haben: Wie genau funktioniert das nun mit dem Super Development Mode? Erweist sich die „neue Art des Debuggens“ als praxistauglich?

Um die Frage beantworten zu können, werde ich in diesem Artikel zeigen, wie man ein GWT-Projekt aufsetzt und welche Möglichkeiten es gibt, mit dem GWT Compiler erstellten JavaScript-Code zu debuggen. Dabei verwende ich zunächst Eclipse, anschließend gehe ich noch kurz auf den SDM in IntelliJ IDEA ein.

Ein neues Webprojekt

Wenn man mit GWT in Eclipse arbeitet, ist es eine gute Idee, das Google-Developer-Plug-in zu installieren. Neben dem Google Plugin for Eclipse 4.4 (Eclipse Luna) kann hier auch das Google Web Toolkit SDK installiert werden. Leider wird über diese Option derzeit das SDK in der Version 2.6 installiert. Version 2.7, die ich verwenden möchte, muss daher per Hand heruntergeladen und installiert werden. Um eine Installation im eigentlichen Sinn handelt es sich dabei nicht: Die heruntergeladene .zip-Datei muss lediglich entpackt werden. Anschließend kann das GWT-SDK über Window | Preferences unter der Option Google eingerichtet werden.

Nach dem obligatorischen Neustart von Eclipse bei der Installation des Plug-ins taucht eine zusätzliche Schaltfläche in der Symbolleiste auf, worüber ich jetzt ein neues Web Application Project erstelle. Selbstverständlich geht alternativ auch der Weg über File | New | Web Application Project.

Im darauffolgenden Dialog wähle ich einen Projektnamen sowie einen Default-Package-Namen. Das Google-SDK wird gemäß des Workspace-Standards voreingestellt; eine Google App Engine brauche ich für dieses Beispiel nicht. Mit Klick auf Finish wird das Default-GWT-Projekt erstellt.

Der Standard: SDM mit Debugging im Browser

Wenn eine GWT-Anwendung nicht als WAR-Datei deployt wird, sondern in der IDE laufen soll, werden zwei Server gestartet: Zum einen der Webserver, auf dem die Anwendung läuft, zum anderen der so genannte Code Server für den GWT-Compiler. Das ist nichts Neues im Vergleich zum bisherigen Development Mode. Das GWT-Plug-in nimmt dem Entwickler erfreulicherweise die meiste Arbeit ab. Mit einem Rechtsklick auf das Projekt und Run As | Web Application (GWT Super Dev Mode) kann die Applikation gestartet werden. In der Konsole kann man den Start des Codeservers verfolgen (Listing 1).

Runing CodeServer with parameters: [-noprecompile, -port, 9876, -sourceLevel, 1.7, -bindAddress, 127.0.0.1, -launcherDir, C:\Users\Holger\Documents\Artikel JavaMagazin - SDM\workspaceSDM\ShowcaseSDM\war, -logLevel, INFO, de.herrmannholger.showcasesdm.ShowcaseSDM]
Super Dev Mode starting up
workDir: C:\Users\Holger\AppData\Local\Temp\gwt-codeserver-3039970899702867796.tmp
Loading Java files in de.herrmannholger.showcasesdm.ShowcaseSDM.
Module setup completed in 2267 ms

The code server is ready at http://127.0.0.1:9876/
Code server started in 2406 ms
waited 480 ms for code server to finish

Eventuell sehen Sie beim Starten in der Konsole die Warnung:
WARNUNG: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.

Die Warnung, so sie denn erscheint, können Sie getrost ignorieren, denn sie hat keine Auswirkung auf die Funktionsweise der Anwendung oder der Server. Wenn Sie sie aber loswerden möchten, legen Sie einen (leeren) Schlüssel Prefs in der Registrierung unter HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft an.

In der Development Mode View können Sie außerdem den gestarteten Webserver sehen. Er belegt den gleichen Port (8888) wie im Development Mode.

Nach dem Starten können Sie zunächst auf die Seite http://127.0.0.1:9876/ wechseln, auf der der Code Server (Abb. 1) läuft. Hier stehen Funktionen zum Ein- und Ausschalten des Development Modes zur Verfügung. Die zugehörigen Buttons können Sie per Drag and Drop in die Favoritenleiste des Browsers ziehen.

Abb. 1: Der GWT Code Server

Abb. 1: Der GWT Code Server

Wenn man die Anwendung ansehen möchte, geht man dazu auf die Startseite, die auf dem Web Server gehostet wird (http://127.0.0.1:8888/). Beim ersten Aufruf erfolgt unmittelbar die Übersetzung des Java-Codes nach JavaScript, anschließend wird die Startseite angezeigt.

Wie aber erfolgt jetzt das Debugging im Browser? Dazu benötige ich die Entwicklertools des Browsers, die sich mit F12 öffnen lassen. Im Reiter erfolgt die Zuordnung der so genannten Source Maps. Hier können Sie mit Strg + P die gewünschte Java-Datei auswählen (eventuell müssen Sie diese Funktion über die Einstellungen erst noch aktivieren). Ich mache das exemplarisch für die Klasse ShowcaseSDM. Sie wird im Source-Fenster des Browsers geöffnet, in dem z. B. auch Code Highlighting implementiert ist. Danach setze ich einen Haltepunkt in die Methode sendNameToServer() (Zeile 112 im unveränderten Beispielcode). Durch Klicken auf den Button Send wird die Funktion ausgeführt – und bleibt beim gesetzten Haltepunkt stehen (Abb. 2).

Abb. 2: Debugging im Browser

Abb. 2: Debugging im Browser

An dieser Stelle können Sie, ganz wie in der IDE, einzelne Zeilen vorwärts steppen (in Chrome mit F10), in Methoden verzweigen (F11) oder den Code komplett weiter ausführen lassen (F8).

Ein wesentlicher Unterschied zum Debuggen im bisherigen Development Mode ist die Anzeige der Variablen (Abb. 3). Im Browser lassen sich nicht die implementierten Java-Variablen untersuchen, stattdessen sieht man dort die JavaScript-Variablen des übersetzten Codes. Das ist sicher gewöhnungsbedürftig, kann aber auch Vorteile haben.

Abb. 3: Anzeige der Variablen im Chrome Debugger

Abb. 3: Anzeige der Variablen im Chrome Debugger

Eine wichtige Frage bleibt bis jetzt noch unbeantwortet: Wie können Änderungen am Quellcode aktiviert werden? Die Antwort ist ganz einfach: In Eclipse ändern, speichern und einen Browser-Refresh durchführen. Dann wird der GWT Compile erneut gestartet und die Anwendung wird mit den Änderungen neu geladen. Eine gute Nachricht ist: Mit dem Super Development Mode wurde ein so genannter „incremental compile“ eingeführt. Er bewirkt, dass der GWT Compiler nicht – wie bisher – sämtlichen Quellcode übersetzt, sondern nur noch die geänderten Klassen übersetzen muss. Bei häufigen Codeänderungen ist das ein echter Vorteil.

Komfortabler geht’s mit dem SDBG-Plug-in

Die bisher gezeigte Methode ist schon ganz gut zu gebrauchen. Vielleicht wäre es aber noch schöner, wenn man direkt in Eclipse debuggen könnte. Auch dafür gibt es einen Ansatz: Das Eclipse-Plug-in SDBG. Mit ihm ist es möglich, eine Verbindung zwischen dem Browser und dem Webserver bzw. Code Server in Eclipse herzustellen. Falls Sie es bislang noch nicht getan haben, ist es jetzt notwendig, das GWT-Eclipse-Plug-in zu installieren. Nach dieser Installation und der Installation des SDBG-Plug-ins können Sie in den Debug Configurations eine neue Konfiguration Launch Chrome erstellen (das SDBG-Plug-in funktioniert nur mit Chrome) (Abb. 4).

Abb. 4: Neue SDBG Konfiguration

Abb. 4: Neue SDBG Konfiguration

Wenn Sie diese Konfiguration ausführen, wird Chrome automatisch gestartet und die Anwendung geladen. Eventuell müssen Sie Eclipse noch bekanntgeben, wo Chrome zu finden ist. Dann nehmen Sie folgenden Eintrag in der Konfigurationsdatei eclipse.ini vor:

-Dchrome.location=<Pfad zur Datei chrome.exe>

Jetzt können Sie Haltepunkte in Eclipse setzen. Lassen Sie sich nicht davon irritieren, dass die Haltepunkte nicht mehr mit einem kleinen Häkchen angezeigt werden – sie funktionieren trotzdem! Nach dem Klicken wird wie gewohnt in die Debug-Perspektive von Eclipse gesprungen, und die Anwendung kann im Debugger durchlaufen werden. Auch in diesem Fall erfolgt die Anzeige der Variablen natürlich in Form von JavaScript-Variablen. Im Grunde handelt es sich um kein anderes Verfahren als beim direkten Debuggen im Browser. Über das Plug-in SDBG wird lediglich die Verbindung zwischen Browser und Quelldatei in Eclipse hergestellt.

Die Alternative: SDM mit IntelliJ

Für das Arbeiten mit GWT-Anwendungen ist bei JetBrains IntelliJ allerdings die Ultimate Edition notwendig, da diese Projekte von der Community Edition nicht unterstützt werden.

Ich erstelle zunächst eine neue GWT-Anwendung „ShowcaseSDM“ mithilfe des integrierten Wizards. Wenn Sie ein bestehendes GWT-Projekt importieren und dieses mit IntelliJ debuggen wollen, achten Sie darauf, dass die Moduleinstellungen korrekt sind: Das Projekt muss als GWT und Webprojekt deklariert sein.

IntelliJ hat in der Version 14 großen Wert auf eine komfortable Unterstützung des Super Development Modes gelegt, sodass das Einrichten einer entsprechenden Debug-Konfiguration ein Kinderspiel ist. Ich benutze den Dialog Run/Debug Configuration, um eine neue GWT-Konfiguration anzulegen. Die meisten Einstellungen sind schon richtig vorbelegt. Wichtig ist hier, dass die Optionen Use Super Dev Mode und with Java Script debugger markiert werden. Als Browser wähle ich Chrome; dieser wird beim ersten Aufruf die Erweiterung JetBrains IDE Support installieren, welche auch von JetBrains entwickelt wird (daher ist davon auszugehen, dass dieses Plug-in auch in Zukunft weiterentwickelt wird). Die Konfiguration sieht schließlich aus wie in Abbildung 5 dargestellt.

Abb. 5: Debug-Konfiguration für das Demoprojekt

Abb. 5: Debug-Konfiguration für das Demoprojekt

Nun starte ich diese Konfiguration im Debug-Modus, was dazu führt, dass zunächst der Code Server gestartet wird (wie gehabt auf Port 9876) und anschließend der Webserver (ebenfalls wie gewohnt auf Port 8888). Chrome wird automatisch gestartet, das Plug-in wird geladen und die Anwendung zunächst nach JavaScript kompiliert.

Das Debuggen ist in diesem Fall genauso einfach wie bei der Verwendung von Eclipse mit dem SDBG-Plug-in: Haltepunkt im Sourcecode setzen und Anwendung ausführen. Ich setze Haltepunkte in den Zeilen 25 und 27 der neu erstellten Beispielanwendung. Wenn ich dann auf Click me klicke, bleibt das Programm am gesetzten Haltepunkt stehen, und ich kann wie bei einer normalen Java-Anwendung durch den Code in IntelliJ debuggen. Natürlich gilt auch hier: Die Anwendung kann nur als JavaScript untersucht werden.

Abb. 6: Analyse der Variablen beim Debuggen in IntelliJ

Abb. 6: Analyse der Variablen beim Debuggen in IntelliJ

Fazit

Das Aufsetzen der Debug-Konfigurationen für den Super Development Mode erwies sich in allen drei Konstellationen als relativ problemlos. Das Debuggen verläuft ebenfalls ohne Schwierigkeiten, jedoch ist die Analyse von Variablen und Stack Trace als JavaScript für Java-Entwickler sicher gewöhnungsbedürftig.

Das Debuggen im Browser fühlt sich anders an, als man das bislang gewohnt ist. Hier hilft das SDBG-Plug-in für Eclipse, das sehr gute Dienste leistet und auf Anhieb reibungslos funktioniert hat. Leider ist man damit auf ein weiteres Plug-in angewiesen, das auch für künftige Releases von Eclipse weiterentwickelt werden muss.

Ähnliches gilt für das Arbeiten mit IntelliJ: Hier ist es die Erweiterung für Chrome, die kompatibel gehalten werden muss. Allerdings wird diese von JetBrains selbst entwickelt, sodass das kein wirkliches Problem darstellen sollte. Zu beachten bei dieser Option ist, dass die GWT-Entwicklung in der Community Edition nicht unterstützt wird und daher die Ultimate Edition lizenziert werden muss.

Aufmacherbild: Closeup of Computer Screen via Shutterstock / Urheberrecht: JMiks

Geschrieben von
Holger Herrmann
Holger Herrmann
Holger Herrmann beschäftigt sich seit über zehn Jahren mit Java, seit einigen Jahren mit Schwerpunkt auf Technologien bei Webanwendungen. Seit 2011 arbeitet er als Entwickler und Softwarearchitekt bei Rödl&Partner.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: