Eclipse Indigo

Java Development Tools: Immer noch ganz vorne dabei

Marc Teufel

Im Jahr 2011 trug das Eclipse-Simultanrelease den Namen Indigo. Im Bereich der Java Development Tools (JDT) sind wieder viele neue Funktionen und Verbesserungen eingeflossen, die Eclipse ganz vorne in der Riege der Top-Java-Entwicklungsumgebungen mitspielen lassen.

JDT Entdeckertour
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!

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

Es ist schon erstaunlich. Erstaunlich, wie es die Entwickler der Java Development Tools (JDT) jedes Jahr schaffen, neue Funktionalität in ihre Entwicklungsumgebung einzubauen, die bei der Softwareentwicklung mit Java auch tatsächlich sinnvoll ist. Und ohne den sich gerade in Entstehung befindlichen Java-7-Support mitzuzählen finden sich tatsächlich mehr als 30 neue Funktionen und Verbesserungen [1] im diesjährigen Release. Neuerungen und Veränderungen gibt es natürlich wieder in unterschiedlichen Bereichen innerhalb des Java Development Toolings. Der Java-Editor ist das zentrale Werkzeug, die Stelle, in der ein Entwickler die meiste Zeit arbeitet. Daher ist es auch nicht verwunderlich, dass die meisten neuen Funktionen sich auf den Java-Editor beziehen. Besonderes Augenmerk des JDT-Teams schien darauf zu liegen, die Produktivität des Entwicklers während seiner Arbeit zu verbessern. Neuerungen gibt es aber auch in anderen Bereichen, etwa dem integrierten Compiler, im Properties-File-Editor und in der JUnit-Integration. Im Rahmen dieses Artikels können natürlich nicht alle Neuigkeiten im Detail besprochen werden, daher sollen einzelne, aus Sicht des Autors interessante neue Features näher betrachtet werden.

Ein JDT, zwei Eclipse-Versionen

Eclipse befindet sich derzeit im Umbruch. Im Rahmen des e4-Projekts wurde nämlich bereits vor geraumer Zeit damit begonnen, nicht nur intern aufzuräumen, sondern auch vieles besser zu machen und die Plattform auf eine modernere technologische Basis zu stellen. Da man nicht von heute auf morgen eine etablierte Plattform austauschen kann, hat man sich entschlossen, einen sanften Übergang von Version 3.x auf 4 durchzuführen. Aus diesem Grund haben wir es in diesem Jahr eigentlich mit zwei Eclipse-Versionen zu tun: dem klassischen 3.x-Zweig und der neuen, auf e4-Technologie basierenden Version. Da es sich beim Java Development Tooling lediglich um einen Satz Plug-ins handelt, die die Java-Entwicklungsumgebung implementieren, können diese ohne Änderung in beiden Versionen verwendet werden. Es ist also egal, ob man das auf 3.7 basierende Indigo-Release verwendet oder mit Eclipse 4.1 arbeitet, die Java Development Tools sind immer dieselben. Damit sind die JDT auch der beste Beweis dafür, dass der in 4.1 enthaltene Compatibility Layer auch gut funktioniert. Er wurde extra entwickelt, um möglichst vielen Plug-ins den Übergang in die schöne neue Eclipse-Welt von morgen zu ermöglichen. Im nächsten Jahr übrigens, dann im Rahmen des Juno-Simultanreleases, wird die Migration zum 4.x-Zweig vermutlich vollzogen sein, wobei man davon ausgehen darf, dass auch der 3.x-Zweig weiterhin gepflegt werden wird.

Java 7

Fünf Jahre nach Veröffentlichung von Java 6 soll die nächste Java-Generation im Juli 2011 nun endlich veröffentlicht werden. Das diesjährige Indigo-Simultanrelease unterstützt Java 7 offiziell leider noch nicht. Die Arbeiten, um Eclipse und Java 7 zusammenzubringen, sind jedoch weiterhin in vollem Gange und können auch schon ausprobiert werden. Hierzu ist für 3.7 und 4.1 eine nachträgliche Installation erforderlich [2]. Die Entwicklung der Java-7-Integration ist zum aktuellen Zeitpunkt schon weit vorangeschritten: So unterstützt der Codeeditor beispielsweise bereits neue Sprachkonstrukte wie Strings in Switches oder das neue Try-with-Ressources-Konstrukt, mit dem man im Quellcode den Zugriff auf Ressourcen, wie etwa Files, deutlich kürzer und übersichtlicher ausdrücken kann als zuvor. Details über den aktuellen Stand der Java-7-Integration in Eclipse finden sich unter [3]. Wichtig an dieser Stelle ist jedoch zu erwähnen, dass die Java-7-Integration noch kein offizieller Bestandteil des Indigo-Releases ist.

Neuigkeiten im Editor

Jede Verbesserung im Java-Code-Editor zielt darauf ab, die Arbeit des Entwicklers weiter zu vereinfachen. Interessant ist zum Beispiel die neue Funktion Open from Clipboard, die sich im Menü Navigate findet. Wenn man diese Funktion aufruft, analysiert Eclipse den Inhalt der Zwischenablage und versucht, entsprechende Java-Klassen in der Entwicklungsumgebung zu finden. Sorgt man etwa dafür, dass der Text toString() in der Zwischenablage landet und ruft man den neuen Befehl auf, wird Eclipse nach kurzer Zeit einen Auswahldialog anzeigen und alle Klassen anbieten, die diese Methode enthalten. Hilfreich ist das ganze beispielsweise dann, wenn man ausgehend von einem Stacktrace schnell an die den Fehler verursachende Stelle navigieren will: einfach die entsprechende Zeile im Trace markieren, in die Zwischenablage übernehmen und die neue Funktion Open from Clipboard in Eclipse aufrufen.

Hyperlinks sind nicht nur im Web eine tolle Sache, auch im Java-Editor sind sie schon seit Langem ein nützliches Mittel, um im Code zu navigieren. Mit Indigo kommen nun drei neue Hyperlinks hinzu: Open Super Implementation, Open Declared Type und Open Return Type. Während Open Super Implementation in den letzten Eclipse-Versionen bereits über das Menü Navigate verfügbar war und nun zusätzlich als Hyperlink zur Verfügung steht, handelt es sich bei den anderen beiden um gänzlich neue Hyperlinks. Open Declare Type bietet bei Variablen die Möglichkeit, unkompliziert zum Typ derselbigen zu navigieren. Bei einer Variablen vom Typ String hat man so die Möglichkeit, in die Implementierung von String selbst zu springen. Andersherum wirkt Open Return Type auf Methoden, indem es die Möglichkeit bietet, in die Implementierung des Typs der Rückgabe zu springen.

Die zahlreichen Quick Assists gehören sicherlich zu den hilfreichsten Fähigkeiten des Eclipse Code Editors, denn sie bieten während der Entwicklung umfangreiche Hilfen in Form von Codevervollständigung und Code Snippets an, wenn man sie mit CTRL+1 aktiviert. Im diesjährigen Release sind auch hier wieder einige neue hinzugekommen. Mithilfe des instanceof-Schlüsselworts kann seit jeher der entsprechende if mit instanceof-Prüfung automatisch erzeugt werden, wobei Eclipse optional auch den Cast des geprüften Objekts auf den tatsächlichen Typ generieren kann. Der neue Quick Assist Introduce new local with cast type bietet nun die Möglichkeit, diesen Cast auf Wunsch auch separat zu erzeugen. Der neue Quick Assist Exchange left and right operands for infix expression dagegen ermöglicht das Drehen von Vergleichswerten, etwa in if-Statments. Verfügbar ist dieser neue Quick Assist für folgende Operatoren: !=, <, <=, > und >=. Unter Verwendung dieses neuen Quick Assists würde also der Ausdruck if ( a != b) in if ( b != a) umgewandelt. Der bereits vorhandene Quick Assist Add paranoiac parentheses wurde in den viel aussagekräftigeren Namen Put expressions in parentheses umbenannt und bietet nach wie vor die Möglichkeit, einzelne Vergleichsaktionen oder Ausdrücke in Klammern zu setzen. Als recht nützlich dürfte sich auch der neue Add missing case statements Quick Assist erweisen, bietet er doch die Möglichkeit, fehlende case-Zweige in Switches automatisch zu erzeugen. Zur Verdeutlichung zeigt Abbildung 1 noch einmal alle Quick Assists in Aktion.

Abbildung 1: Viele neue Quick Assists erleichtern die tägliche Programmierarbeit

Compiler

Der in Java 1.4 eingeführte assert-Befehl hat sich in der Vergangenheit als sehr nützlich beim Testen und Debuggen erwiesen, denn er bietet die Möglichkeit sicherzustellen, dass ein bestimmter Sachverhalt im Code auch eingehalten wird. Der Entwickler tut dies, indem er den assert-Befehl gefolgt von einem booleschen Ausdruck schreibt, von dem er ausgeht, dass dieser immer true ergibt. Zur Laufzeit wirkt ein assert nur, wenn Assertions aktiviert sind. Dann würde ein AssertionError geworfen werden, sobald das Ergebnis eines asserts false ergibt. Das Verwenden von assert ist in JDT nun weiter verbessert worden. Wird die per Default abgeschaltete neue Option Include ‚assert‘ in null analysis in der Preference Page Java | Compiler | Errors/Warnings aktiviert, nimmt JDT Rücksicht auf assert-Befehle, in denen zugesichert wird, dass eine Variable null ist. Wird eine solche Variable beispielsweise nach einem assert nochmals auf null geprüft, kann Eclipse dies erkennen und entweder mit einer Warnung oder einem Fehler im Editor dokumentieren.

In der Preference Page Java | Compiler | Errors/Warning gibt es übrigens mittlerweile derart viele Einstellungsmöglichkeiten, dass die nun neu hinzugekommene Möglichkeit zu filtern tatsächlich Sinn macht. Abbildung 2 zeigt den neuen Filter bei der Arbeit: Stellt man eine Tilde vor/nach den Suchwert, wird nicht nur nach dem Namen der entsprechenden Einstellung gesucht, sondern auch der Einstellungswert selbst berücksichtigt. Weiterhin erkennt der Compiler in der neuen Eclipse-Version nun noch mehr Variablen, die nicht benutzt sind, und zeigt sie an. Der Compiler bemerkt darüber hinaus auch, ob eine Methode statisch deklariert werden könnte und schlägt dies vor, wenn die entsprechenden Einstellungen (wieder in der Error/Warnings Preference Page) aktiviert sind.

Abbildung 2: Die zahlreichen Compileroptionen können nun nach Name und Einstellung gefiltert werden

Dies und das

Im aktuellen Java Development Tooling finden sich natürlich auch wieder einige interessante Verbesserungen, die eher in die Kategorie „Kleinigkeit“ fallen, aber trotzdem kurz erwähnt werden sollen. Als besonders hilfreich hat sich die nun neu hinzugekommene Möglichkeit erwiesen, beim Debugging im Rahmen von Step Into auf das Durchlaufen von Getter und Setter zu verzichten. Dies erreicht man durch das Aktivieren der neuen Optionen Filter simple Setters und Filter Simple Getters in der Preference Page Java | Debug | Step Filtering (Abbildung 3). Sind diese beiden Filter aktiviert, wird beim Debuggen in eine Methode wie getTransportauftrag(eingabe.getNummer()) eben nicht mehr zuerst in die Methode getNummer() gesprungen, sondern diese übersprungen, und man landet direkt in getTransportauftrag. Ein sehr nützliches Feature, weil man so beim Debuggen unter Umständen viel schneller in die Methode gelangt, die man eigentlich untersuchen möchte.

Hilfreich kann weiterhin auch sein, dass man jetzt über die Preference Page Java | Editor | Syntax Coloring eine neue Einstellungsmöglichkeit hat, um abstrakte Klassen im Codeeditor farblich von anderen Klassen zu unterscheiden. Das benötigt man nicht unbedingt, ist aber „nice to have“. Ganz hilfreich im Zusammenhang mit JUnit dürfte die nun neu hinzugekommene Möglichkeit sein, Test Suites auch für JUnit 4 generieren zu können. Auch eine kleine Erweiterung im Properties-File-Editor soll an dieser Stelle nicht unerwähnt bleiben: Es besteht nämlich jetzt die Option, mithilfe eines neuen Quick Assist (CTRL+1) Backslashes automatisch „zu escapen/unescapen“.

Abbildung 3: Step-in-Filter für das Debuggen in „Getter“ und „Setter“ aktivieren/deaktivieren

Fazit

Dieser Artikel konnte natürlich nicht alle neuen Funktionen der JDT-Indigo-Version beschreiben. Für eine detaillierte Auflistung aller neuen Features im Bereich JDT, aber auch in der Eclipse-Plattform, sei an dieser Stelle nochmals auf [1] verwiesen. Auch im Jahr 2011 haben es die Entwickler der Java Development Tools wieder geschafft, einige neue Funktionen einzubauen, die nicht nur beeindrucken, sondern auch einen echten Mehrwert darstellen und das bisher Vorhandene weiter verbessern. Insgesamt lässt sich daher nur feststellen, dass sich Eclipse nach wie vor zu den Top-Entwicklungsumgebungen im Java-Umfeld zählen darf.

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.