Eclipse Galileo

Java Development Tools: Entdeckertour

Marc Teufel

Die Java Development Tools (JDT) für Eclipse sind für viele Java-Entwickler die präferierte Umgebung, in der sie täglich ihre Java-Anwendungen bearbeiten. Kontinuierlich werden die JDT um neue Features ergänzt, die im Rahmen der jährlichen Eclipse-Release-Trains im Juni offiziell freigegeben werden. In der Serie „JDT Entdeckertour“ zeichnen wir die JDT-Verbesserungen von 2009 bis heute nach. Schauen Sie sich den einen oder anderen Trick bei der Arbeit mit Eclipse ab und entdecken Sie versteckte JDT-Funktionen, die Ihnen das Entwicklerleben leichter machen!

JDT Entdeckertour
Serienteile:
– Eclipse Galileo: Entdeckertour
Eclipse Helios: Feinschliff
Eclipse Indigo: Immer noch ganz vorne dabei
Eclipse Indigo: Sieben
Eclipse Juno: Alles gleich, doch vieles anders
– Eclipse Kepler: Durststrecke

Im Juni 2009 hat die Eclipse Foundation ihr jährliches Simultanrelease Galileo freigegeben. Dieser Beitrag gibt einen Überblick einiger Neuigkeiten im Bereich JDT.

Standen frühere Eclipse-Simultanreleases noch im Zeichen der Jupitermonde Callisto, Europa und Ganymede, so hat man sich in diesem Jahr für einen ganz neuen Codenamen entschieden: Galileo [1]. Bei Galileo handelte es sich um eine Raumsonde auf Entdeckertour. Aufgabe der Sonde war es nämlich, den Jupiter zu erforschen, ehe sie ebendort verglühen würde.

In den letzten Jahren wurde insbesondere im Bereich der Java Development Tools (JDT) im Eclipse-Projekt viel getan, sodass man bereits in der vorangegangenen Version einen Stand erreicht hatte, der nahezu keine Wünsche mehr offen zu lassen schien. Auf Grund dieses erstaunlichen Reifegrades darf man in der neuesten Version nun freilich auch keine Wunderwerke bzw. spektakuläre neue Funktionen erwarten. Die Änderungen liegen dieses Mal viel mehr im Detail, aber einige bringen in jedem Fall wieder echten Mehrwert in die IDE. Gehen wir also ebenfalls auf Entdeckertour und erkunden, was sich bei JDT im letzten Jahr getan hat.

Detailverbesserungen

Bereits seit Längerem verfügbar ist eine Funktion in Eclipse, mit der man ausführbare Jar-Dateien exportieren kann. Der entsprechende Assistent, der den Entwickler beim Erzeugen solcher Jar-Dateien unterstützt, ist unter Export … | Java | Runnable Jar file verfügbar. In der aktuellen Version wurde dieser Assistent nun dahingehend erweitert, dass es jetzt auch möglich ist, abhängige Jar-Dateien mit in den Export zu nehmen. Genaugenommen hat man hier über entsprechende Radio-Buttons nun die Qual der Wahl: Abhängige Bibliotheken lassen sich entweder als komplettes Jar oder in ausgepackter Form in den Export aufnehmen.

Der Open-Type-Dialog (ctrl+Shift+T) dürfte einer der am meisten benutzten Dialoge in Eclipse sein, wenn es darum geht, Klassen zu suchen und zu öffnen. Einfach Dialog öffnen, Suchbegriff (mit oder ohne Jokerzeichen) eingeben und schon hat man die gesuchte Klasse ohne langwieriges Navigieren im Projektbaum gefunden und ganz schnell im Java-Editor geöffnet. Im Open-Type-Dialog wurde die Anzeige der Suchergebnisse nun so gestaltet, dass die Suchbegriffe hervorgehoben dargestellt werden. Abbildung 1 zeigt den überarbeiteten Open-Type-Dialog.

Abb. 1: Suchergebnisse werden im Open-Type-Dialog nun hervorgehoben dargestellt

Haben Sie sich eigentlich auch schon darüber geärgert, dass die Codeformatierung (Ctrl+Shift+F) in der Default-Einstellung umgebrochene Zeilen immer in eine Zeile zusammenfasst? Mit der neuen Option Never join line im Line-Wrapping-Tab eines Profiles unter Java | Code Style | Formatter kann man dieses lästige Verhalten ab sofort auf Wunsch abschalten. In JDT finden sich neben den bisher besprochenen noch viele weitere Detailverbesserungen: So können Working-Sets jetzt alphabetisch sortiert werden, das Rename Refactoring ist nun auch über einen Quick Fix (Ctrl+1) erreichbar und der Javadoc Viewer wurde nochmals überarbeitet und unterstützt jetzt neben dem bisher vermissten Tag {@inheritDoc} auch umfassendes Hyperlinking. Im Java-Editor hat man ab sofort die Möglichkeit, mit Doppelklick auf den Anfangs- oder Endmarker eines Kommentars den kompletten Kommentar zu markieren.

JUnit 4.5

Das Schreiben von Unit-Tests in Java-Projekten ist dieser Tage Standard. Dementsprechend bieten die JDT in Eclipse auch schon von Anfang an ein entsprechend gutes Tooling zum Schreiben und Ausführen von Unit-Tests. Die aktuelle Fassung bringt nun JUnit in der Version 4.5 mit, was insbesondere bedeutet, dass Unit-Tests jetzt mit der neuen assert-Methode assertThat geschrieben werden können. Dieser neuen Methode (verfügbar in JUnit seit Version 4.4) übergibt man im Test zwei Parameter: den tatsächlichen, aktuellen Wert (bei assertEquals übergibt man diesen Wert als zweiten Parameter) und einen Matcher, mit dem die zu prüfende Bedingung ausgedrückt wird. Wer mehr über assertThat erfahren will, möge sich [2] und [3] genauer ansehen.

Quelltexthyperlinks abermals verbessert

Von jeher angenehm im Java-Editor sind die hilfreichen Links, die zur Verfügung gestellt werden, wenn man die Ctrl-Taste drückt und sich mit der Maus z. B. auf eine bestimmte Methode bewegt, die man irgendwo im Quelltext aufruft. Ein Klick hierauf und der Editor zeigt den Quellcode dieser Methode an. Mithilfe dieser sinnvollen Funktion hat man also die Möglichkeit, durch den Quelltext einer Anwendung zu browsen. Der Sourcecode fühlt sich so quasi wie ein HTML-Dokument an und bietet dem Entwickler die Möglichkeit, sehr schnell im Quelltext umherzuspringen. Ein Problem waren dabei jedoch immer Methodenaufrufe in Klassen, die ein bestimmtes Interface implementieren. Der Link, der bei einem solchen Konstrukt vom Editor angeboten wurde, hat in der Vergangenheit stets auf die (leere) Methode im Interface verwiesen. Ein direktes Springen zur Methode in der Implementierung war dagegen nicht möglich. In der aktuellen Version wird nun genau dies möglich: Anstatt direkt ins Interface zu springen, wird ein kleines Pop-up-Menü eingeblendet, in dem man wählen kann, ob man zum Interface (Declaration) oder in die Implementierung gelangen möchte. Gibt es zu dem verwendeten Interface mehr als eine Implementierung, wird anstatt zur Implementierung zu springen der bekannte Type-Hierarchy-Dialog angezeigt, in dem man sehen kann, welche Klassen das betreffende Interface implementieren. Das Ganze funktioniert selbstverständlich auch mit abstrakten Klassen.

equals() & hashCode()

Die Java-Oberklasse java.lang.object hat zwei wichtige Methoden: equals() und hashCode(). Diese beiden Methoden sind sehr wichtig, wenn Klasseninstanzen verglichen werden sollen oder wenn Klassen mit Collections interagieren. Beide Methoden sollen immer zusammen implementiert werden [4]. Eclipse kann nun beim Kompilieren eine Warnung oder einen Fehler von sich geben, wenn beim Überschreiben von equals() vergessen wurde, hashCode() ebenfalls zu überschreiben. Entsprechende Quick Fixes zum Erzeugen der fehlenden Methoden stehen natürlich auch zur Verfügung. Dummerweise ist dieses hilfreiche Feature in der Default-Einstellung nicht aktiviert, kann aber in den Preferences auf der Seite Java | Compiler | Error/Warnings im Bereich Potential Programming Problems eingestellt werden. Der bereits aus älteren Versionen bekannte Dialog zum Erzeugen von equals() und hashCode() wurde außerdem mit einer zusätzlichen Auswahlmöglichkeit ausgestattet, über die man steuern kann, ob die im generierten Code enthaltenen if-Statements als Block mit geschweiften Klammern generiert werden sollen.

toString()

Eine weitere sinnvolle Erweiterung ist der neue Dialog zum Generieren von toString()-Methoden. Erreichbar ist die Maske über das Source-Menü. Wie man in Abbildung 2 sehen kann, hat man zunächst die Möglichkeit festzulegen, welche Felder oder Methoden in der toString()-Methode ausgewertet werden sollen. Die große Anzahl an zusätzlichen Einstellungen, die direkten Einfluss auf den generierten Code nehmen (String aneinanderhängen oder über String Builder arbeiten? String über String.format formatieren oder ganz eigenes Format vorgeben?) runden den positiven Gesamteindruck dieser neuen Funktion ab.

Abb. 2: Ein neuer Dialog zum Generieren von toString()

Identische Werte vergleichen – der Compiler merkt‘s!

Beim Vergleichen, z. B. im Rahmen von if-Statements, erkennt der Compiler nun automatisch, wenn zwei identische Werte miteinander verglichen werden. Findet der Compiler einen solchen Vergleich im Code, wird hier in der Default-Einstellung eine Warnung ausgegeben. Selbstverständlich kann man diese Prüfung nach Bedarf auch abschalten oder anstelle der Warnung einen Fehler ausgeben lassen. Die Konfiguration erfolgt wie üblich in den Preferences unter Java | Compiler | Error/Warnings in der Sektion Potential Programming Problems.

case-Blöcke ohne break?

Ebenfalls in der Sektion Potential Programming Problems findet sich die recht interessante Einstellung ’switch‘ case fall-through. Diese Einstellung ist in der Standardkonfiguration deaktiviert (Ignore). Wenn man hier entweder auf Warning oder Error umstellt, reagiert der Compiler, wenn in einem switch-Statement ein case-Block nicht mit break abgeschlossen wurde und zeigt eine Warnung oder einen Fehler an. Mit dieser Funktion kann man also recht schnell herausfinden, welche case-Blöcke womöglich nicht korrekt beendet wurden und daher fehlerhaft sind. Sie stört aber, wenn man an einer bestimmten Stelle den break ganz bewusst weglassen möchte. In Java 5 könnte man hier die Annotation @SuppressWarnings(„fallthrough“) verwenden.  Mit der aktuellen Fassung der JDT gibt es nun ganz neu auch die Möglichkeit, dem Compiler mit Hilfe des Kommentars //$FALL-THROUGH$ mitzuteilen, dass der Durchlauf bzw. das Weglassen von break, an dieser Stelle explizit gewünscht ist. Interessant ist diese Alternative in Situationen, in denen keine Annotations zur Verfügung stehen oder diese nicht verwendet werden dürfen.

Neuigkeiten auch vom Compare-Editor

Hand angelegt haben die Entwickler auch beim Compare-Editor, der sich von nun an viel mehr wie der Java-Editor anfühlt. Im Compare-Editor darf ab sofort nach Belieben editiert, kopiert, verschoben, gelöscht und formatiert werden. Außerdem stehen nun Codevervollständigung, Quelltexthyperlinks, die Anzeige der Klassenstruktur (Quick Outline, Ctrl+O) und das Anzeigen von Javadoc zur Verfügung. Ferner aktualisiert der Compare-Editor seine Struktur jetzt direkt bei der Eingabe und zeigt die Unterschiede an.

Fazit

Spektakuläre neue Features gibt es zwar im Galileo-Release, nicht jedoch im Umfeld der Java Development Tools (JDT). Vielmehr darf sich der Java-Entwickler auf viele Detailverbesserungen und einige sinnvolle neue Funktionen freuen, z. B. den toString()-Generator oder den stark überarbeiteten Compare-Editor. Die Liste an Änderungen in JDT ist natürlich wesentlich länger als die in diesem Artikel besprochenen Themen, daher empfiehlt sich in jedem Fall auch das Sichten der „New & Noteworthy“-Dokumente des Eclipse-3.5-Entwicklungszweiges [5].

Insgesamt bleibt der Eindruck, dass die neu hinzugekommenen Funktionen in JDT die Programmierung mit Eclipse weiter vereinfachen und den Entwickler, vorausgesetzt er setzt die Werkzeuge richtig ein, noch produktiver machen können.

Geschrieben von
Marc Teufel
Marc Teufel
Marc Teufel arbeitet als Projektleiter und Softwarearchitekt bei der hama GmbH & Co KG und ist dort für die Durchführung von Softwareprojekten im Bereich internationale Logistik zuständig. Er ist Autor zahlreicher Fachartikel im Web-Services- und Eclipse-Umfeld. Er hat drei Bücher zu Web Services veröffentlicht, sein aktuelles Buch „Eclipse 4 – Rich Clients mit dem Eclipse 4.2 SDK“ ist kürzlich bei entwickler.press erschienen.
Kommentare

Schreibe einen Kommentar

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