Eclipse Helios

Java Development Tools: Feinschliff

Marc Teufel

Im Juni 2010 hat die Eclipse Foundation ihr Simultan-Release Helios veröffentlicht. Sowohl die Eclipse Platform als auch die Java Development Tools (JDT) waren wieder in aktualisierten Fassungen dabei. Blicken wir auf einige der interessanten Neuerungen.

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

Bei der Eclipse Platform handelt es sich um das grundlegende Rahmenwerk, auf dem alle Werkzeuge aus dem Eclipse-Universum aufsetzen. Völlig unabhängig davon, ob man Softwareentwicklung unter Eclipse etwa mit einer C++- oder Java-IDE betreibt, ist die Plattform immer dieselbe. Die entsprechende IDE setzt mit ihren Plug-ins lediglich auf diesen Grundstock auf. Die Entwickler, die an dieser grundlegenden Plattform arbeiten, legen mit der aktuellen Fassung eine Version vor, die sich auf einer sehr großen Anzahl von Betriebssystemen sowohl im 32- als auch 64-Bit-Modus installieren lässt. Das gilt für die Betriebssysteme aus dem Hause Microsoft genauso, wie alle Arten von unixoiden Betriebssystemen (Solaris, Linux, Mac OS X). So ist unter anderem nun Unterstützung für PowerPC-64-Bit und Ubuntu (in der aktuellen Version 10.04) hinzugekommen. Die Ubuntu-Unterstützung ist für Eclipse insofern wichtig, weil es sich beim 10.04er Ubuntu um ein so genanntes LTS-Release handelt, also eine Version mit langfristiger Unterstützung (Long Term Support) seitens des Herstellers. Deshalb muss davon ausgegangen werden, dass diese Ubuntu-Version eine sehr weite Verbreitung finden wird, was letztlich auch für die Eclipse Foundation die Motivation gewesen sein dürfte, eine gute Integration in dieses Betriebssystem anzubieten. Aber auch das Zusammenspiel von Eclipse mit dem (im Vergleich zu Windows Vista) deutlich besser angenommenen Windows 7 ist im Detail verbessert worden. So wurde eine Funktion hinzugefügt, die Fortschrittsbalken nicht nur innerhalb von Eclipse darstellt, sondern den aktuellen Zustand des Fortschritts auch in der neuen Windows-7-Taskleiste darstellt und animiert. Des Weiteren wurde die Platform dahingehend erweitert, dass man nun endlich Dateien direkt von der Kommandozeile aus in Eclipse öffnen kann. Verknüpft man beispielsweise .java- oder .xml-Dateien mit der Eclipse Executable, werden diese Dateien bei Doppenklick in Eclipse geöffnet. Läuft bereits eine Instanz von Eclipse, wird die entsprechende Datei in der laufenden Instanz geöffnet.

In den letzten Jahren ist gerade der Bereich der Import- und Export-Wizards immer umfangreicher geworden. Für eine Vielzahl von Aufgaben existieren verschiedene Wizards zum Importieren und Exportieren. Um einen speziellen Wizard aus einem bestimmten Bereich leichter zu finden, kann man diese jetzt auch mithilfe von Schlüsselwörtern filtern. Wählt man beispielsweise im Projekt-Explorer die Funktion Export… und gibt dann als Schlüsselwort „jar“ ein, werden nur noch die Exporter angezeigt, mit denen man Jar-Files exportieren kann.

Ressourcen besser finden

Der Open-Ressource-Dialog, schon immer eine echte Innovation, um mal eben schnell eine XML-Konfiguration oder ein Ant-Skript im Projekt zu finden, wurde um zwei weitere spezielle Suchmöglichkeiten erweitert. Die erste Erweiterung sind die so genannten „Path Patterns“. Hier schreibt man seinen Suchstring einfach zwischen zwei Schrägstrichen. Angezeigt werden dann alle Dateien im Workspace, die diesen Suchwert an beliebiger Position enthalten. Selbstverständlich kann man dieses Verfahren auch mit Jokerzeichen kombinieren, wie Abbildung 1 zeigt. Die andere neue Suchmöglichkeit trägt den Namen „Relative Path“ und bietet die Option, ein Prefix ähnlich „./“ nach Ressourcen in dem Ordner zu suchen, in dem sich die aktuelle Selektion befindet oder die Datei, die gerade im aktiven Editor geöffnet ist. Abbildung 2 zeigt ein Beispiel: Hier ist im aktiven Editor die Java-Klasse TestSetup aus dem Package junit.extensions geöffnet. Gibt man im Open-Ressource-Dialog nun „./T“ ein, findet der Dialog alle Dateien im gleichen Package (beziehungsweise Ordner), die mit T beginnen.

Apropos JUnit: Eclipse liefert jetzt übrigens zwei Versionen des JUnit-Plug-ins mit, einmal die Version 3.8.2 und für Freunde von modernem, annotationsgetriebenem Unit-Testing die aktuelle JUnit-Version 4.8.2.

Doch zurück zum Open-Ressource-Dialog. Eine weitere nützliche Neuerung ist die Tatsache, dass der Dialog Suchergebnisse nun so sortiert, dass der ganz am Anfang des Suchergebnisses dargestellte Vorschlag der aktuellen Selektion oder dem aktuellen Editor am nächsten kommt.Abb. 1: Alle Dateien zwischen den Schrägstrichen werden im Workspace gefunden

Abb. 2: Das Präfix „./“ markiert den aktuellen Ordner als Ausgangspunkt der Suche

@Override

Bereits mit Java 5 wurde die Annotation @Override eingeführt. Verwendet werden soll diese Annotation, um Methoden zu markieren, die man aus abgeleiteten Klassen überschreibt. Damit wird der Code insgesamt nicht nur übersichtlicher, weil man auf einen Blick sieht, welche Methode überschrieben wurde und welche nicht. Der Java Compiler ist darüber hinaus auch in der Lage, festzustellen, ob eine überschriebene Methode auch tatsächlich mit der Methodensignatur der zu überschreibenden Methode in der Oberklasse übereinstimmt. Gelingt dem Compiler kein Match, kann er entsprechend einen Fehler ausgeben. Dem Entwickler wird so viel schneller klar, dass er zwar eine Methode überschreiben wollte, sich offensichtlich aber vertippt hat. JDT unterstützt bereits seit Längerem die @Override-Annotation und zeigt folgerichtig auch einen entsprechenden Fehler an, wenn eine mit der Annotation überschriebene Methode von der Signatur her nicht mit einer Methode aus der abgeleiteten Klasse übereinstimmt. Neu hinzugekommen ist in Java 6 auch die Möglichkeit, mit @Override-Methoden zu markieren, die von einem Interface implementiert wurden. Eclipse ist in der aktuellen Version erstmals in der Lage, zu erkennen, ob eine aus einem Interface implementierte Methode mit der Annotation versehen wurde. Leider ist die soeben beschriebene Funktion zum Umgang mit @Override per Default abgeschaltet. Um sie zu aktivieren, muss in den Preferences auf der Seite Java Compiler | Error/Warnings im Bereich Annotations die entsprechende Einstellung (Missing @Override Annotation) von „Ignore“ am besten auf „Warning“ umgestellt werden. Im gleichen Einstellungsfenster findet sich auch die Möglichkeit, diese neu hinzugekommene Unterstützung von @Override auf Interfaces an- beziehungsweise auszuschalten. Insgesamt bleibt festzuhalten, dass sich die angesprochene Annotation als nützliches kleines Helferlein herausstellen kann, um auf der einen Seite den Überblick über den eigenen Code zu bewahren, und um auf der anderen Seite schon während der Entwicklung Fehler schneller zu erkennen.

Unused Object Allocation

Eclipse ist mit einer neuen Einstellung im Bereich Java Compiler | Error/Warnings auf der Seite Potential Programming Problems über die neue Einstellung „Unused object allocation“ in der Lage, nicht verwendete Objekte zu erkennen und entweder eine Warnung oder einen Fehler auszugeben, wenn der Compiler über ein derartiges, nicht verwendetes Objekt stolpert. Die Funktion ist in der Standardeinstellung abgeschaltet. Nicht zu verwechseln ist dieses neue Feature jedoch mit der bereits schon seit Langem enthaltenen Compilerprüfung, ob eine Objektvariable verwendet wird oder nicht. Abbildung 3 zeigt ein Beispiel für beide Prüfungen. Der definierte String wird einfach nicht verwendet und daher mit einem Warning dargestellt, der auf diesen Umstand hinweist. Bei der IllegalArgumentException stellt der JDT-Compiler jedoch fest, dass dieses Objekt nirgendwo benutzt wird und bietet zur Lösung des Problems auch gleich drei hilfreiche Quick Fixes an: entweder ganz entfernen oder ein Umstellen der Anweisung, sodass die Exception entweder geworfen oder zurückgegeben wird.

Abb. 3: Nicht verwendete Objekte werden von Eclipse erkannt

Javadoc

Sehr schön in Eclipse gelöst war seit jeher die Integration mit Javadoc zur Dokumentation von Quelltext. Man bewegt im Java-Editor den Mauspfeil auf ein Objekt oder eine Annotation, und Eclipse zeigt das zugehörige Javadoc (sofern vorhanden) übersichtlich in einer Art übergroßem Tooltip, dem so genannten Javadoc Hover, an. Das Javadoc Hover wurde nun dahingehend erweitert, dass auch Annotationen korrekt dargestellt werden. Recht hilfreich ist auch die neu hinzugekommene Unterstützung von {@value} innerhalb von Javadoc. Abbildung 4 zeigt, wie es funktioniert: Damit im Javadoc die Konstante ID_PLUGIN mit dem ihr zugewiesenen Wert dargestellt werden kann, wird im abgebildeten Code das Konstrukt {@value} verwendet, umrahmt von einem <code>-Tag, der wiederum dafür sorgt, dass der Wert in der richtigen Formatierung dargestellt wird.

Darüber hinaus wurde die Funktion Open External Javadoc im Menü Navigate umbenannt in Open Attached Javadoc und zeigt eine extern auf der Platte liegende Javadoc-Dokumentation in dem Browser an, der in den Preferences unter General | Web Browser eingestellt ist. Sollte Eclipse dieses externe Javadoc nicht automatisch finden, so kann im Dialog mit den Projekteigenschaften in der Rubrik Javadoc Location der entsprechende Pfad manuell angegeben werden.

Abb. 4: Der Javadoc-Hover rendert die value-Angabe nun korrekt

Neues bei den Refactorings

Refactoring, entstanden eigentlich im Kontext agiler Softwareentwicklung, hat sich mittlerweile zu einer Standardtechnik entwickelt, die heutzutage jeder Softwareentwickler beherrschen sollte. Mit dem so genannten „Eclipse Way“ setzen die JDT-Entwickler darüber hinaus ihren eigenen agilen Entwicklungsprozess um und führen bei der täglichen Entwicklungsarbeit vermutlich sehr häufig selbst Refactorings durch. Nur so lässt sich erklären, dass Eclipse eine solch solide Unterstützung für Refactorings im Angebot hat. Und natürlich hat sich in diesem Jahr auch wieder etwas in diesem Bereich getan, zum Beispiel im Refactoring Extract Method. Mit dieser hilfreichen Funktion ist man in der Lage, unübersichtliche Stellen im Quelltext auseinander zu ziehen und bestimmte Teile in separate Methoden auszugliedern. Ab sofort kann dieses Refactoring auch mit Quellcode umgehen, der den Befehl continue enthält. Wichtig dabei ist nur, dass vor dem Ausführen dieses Refactorings nicht nur der Block mit dem continue-Befehl selbst markiert wurde, sondern auch noch die folgende Zeile/Anweisung. Andernfalls hat JDT kaum Chancen, eine sinnvolle Methode daraus zu generieren (Abb. 5). In der gleichen Funktion haben die Entwickler außerdem noch eine Plausibilitätsprüfung eingebaut. Wenn man versucht, Extract Method auf einen Codeblock auszuführen, der mehrere Zuweisungen auf unterschiedliche Variablen enthält, zeigt Eclipse nun eine Liste aller Variablen an, die im Konflikt zueinander stehen und aufgrund dessen das Extrahieren in eine neue Methode nicht möglich ist.

Lange an Bord ist auch schon das Refactoring Convert Member Type to Top Level. Mit diesem Refactoring war man in der Lage, Inner Classes in eigene Dateien auszulagern. Hierzu musste lediglich im Java-Editor der Cursor in die entsprechende Inner Class platziert und die genannte Refactoring-Funktion ausgewählt werden. Für die gewählte Inner Class wurde dann eine eigene Datei im gleichen Package und Ordner angelegt und automatisch auch alle Referenzen angepasst. Dieses Refactoring ist im Helios-Release nach wie vor enthalten, wurde jedoch in Move Type to new File umbenannt. Das Refactoring kann neben Inner Classes nun auch eingesetzt werden, wenn man in einer .java-Datei neben der Hauptklasse noch sekundäre Klassendefinitionen hat (dürfen weder private noch public deklariert sein) und diese sauber in separate Java-Quellcodedateien auslagern will.

Abb. 5: Das Extract Method Refactoring kann aus dem selektierten Quellcode keine sinnvolle Methode extrahieren

Nice to have

Und wie jedes Jahr finden sich natürlich auch im diesjährigen JDT-Release wieder einige kleine Erweiterungen und Verbesserungen, die das Entwicklerleben angenehmer gestalten. Ein paar von diesen „Nice to have’s“ sollen im Folgenden dargestellt werden.

So finden sich für den Bereich automatische Quellcodeformatierung in den Preferences unter Java | Code Style | Formatter im Reiter Line Wrapping recht interessante neue Optionen, um den Zeilenumbruch im Quelltext zu beeinflussen. Es kann beispielsweise eingestellt werden, dass beim Einsatz von Annotationen mit Attributen jedes Attribut in einer eigenen Zeile stehen soll. Auf der gleichen Seite kann außerdem (optional) eingestellt werden, ob in einer Methodendeklaration Modifier, Rückgabewert und Name der Methode in jeweils eigenen Zeilen stehen sollen.

Ganz neu hingekommen ist der Reiter On/Off Tags auf gleicher Ebene wie Line Wrapping. Mit dieser neuen Funktion können Start- und Ende-Tags definiert werden, die man als Kommentar in den Quelltext einstreuen kann, um festzulegen, welche Bereiche des Quellcodes vom Eclipse Formatter berücksichtigt werden soll und welche nicht. In der Standardeinstellung ist diese Funktion deaktivert, außerdem ist @formatter:on als Start-Tag und @formatter:off als Ende-Tag voreingestellt. Die Bezeichnungen dieser Tags können jedoch frei festgelegt werden. Sind die On-/Off-Tags aktiviert, kann man nun bestimmen, für welche Bereiche des Quelltexts der automatische Code-Formatter von Eclipse aktiv werden soll, in dem man die Tags als Kommentare in den Quelltext schreibt. Dabei ist es wichtig zu verstehen, dass zu Beginn die Automatikformatierung immer angeschaltet ist. Will man also schon von der ersten Zeile an einen bestimmten Bereich vom Code-Formatter ausschließen, so muss direkt in der ersten Zeile der entsprechende Off-Tag in einem Kommentar eingefügt werden. Das An- bzw. Abschalten des Code-Formatters wird jeweils nach der Kommentarzeile mit Tag aktiv. Abbildung 6 zeigt ein Beispiel: In den ersten Zeilen ist die automatische Formatierung noch aktiv, erst mit Beginn der Methode foo() wird die automatische Formatierung mithilfe des Off-Tags abgeschaltet.

Auch im Bereich Debugging gibt es von einer recht interessanten Neuerung zu berichten: Im Variables-View kann man nun optional eine zusätzliche Spalte sehen, in der die Anzahl der aktuell verwendeten Objektinstanzen angezeigt wird (Instance Counts). In der Standardeinstellung ist diese Information nicht sichtbar, sie kann aber sehr einfach über das View-Menü unter Layout | Select Columns… aktiviert werden. Diese neue Funktion ist allerdings erst ab Java 1.6 verfügbar und funktioniert nur mit Objektinstanzen und nicht mit primitiven Typen wie int, boolean und so weiter (Abb. 7).

In großen Projekten finden sich meistens so viele Java-Klassen in den unterschiedlichsten Packages, dass es oftmals schwer wird, die Übersicht zu behalten. Im Mylyn-Projekt wird daher bereits versucht, durch eine so genannte aufgabenfokussierte (Task-focused) UI nur die Bestandteile des Projekts im Projekt-Explorer darzustellen, an denen man gerade arbeitet beziehungsweise die im Zusammenhang mit der gerade zu erledigenden Aufgabe stehen. Alle anderen Projektbestandteile werden einfach ausgeblendet. In der aktuellen JDT-Version findet sich neben Mylyn nun eine weitere, recht nützliche Funktion, um große Projekte übersichtlicher im Package Explorer darzustellen. Man stelle sich vor, man hat ein Projekt mit sehr vielen Klassen in einem bestimmten Package. Die Idee ist nun, lange Package-Namen nur noch durch Abkürzungen (Abbreviations) darzustellen und so für eine bessere Übersichtlichkeit zu sorgen. Abbildung 8 stellt im Vergleich dar, wie dieses neue Feature in Eclipse wirkt: Im oberen View sieht man die klassische Darstellung, darunter die mit verkürzten Package-Namen. Die Konfiguration hierfür erfolgt in den Preferences unter Java | Appearance. Die Checkbox Abbreviate package names muss aktiviert werden. Zusätzlich ist im Textfeld darunter anzugeben, welche Package-Namen auf welches Kürzel gemappt werden sollen. In Listing 1 finden sich die Mappings, die für die in Abbildung 8 dargestellten Abkürzungen verwendet wurden. Mit dem Hash-Zeichen (#) lassen sich einzelne Mappings auskommentieren.

Abb. 6: Mit den neuen On-/Off-Tags kann im Quellcode festgelegt werden, für welche Bereiche der Code-Formatter aktiv werden soll

Abb. 7: Die Variable-View kann in Debugging-Sitzungen nun auch anzeigen, wie viele Instanzen von einem Objekt existieren

Abb. 8: Mehr Übersichtlichkeit durch Abkürzung von Package-Namen, oben ohne Abkürzungen, unten mit

org.eclipse.ui={UI} 
org.eclipse.ui.texteditor={T} 
org.eclipse.ui.internal.texteditor=[iT]

Fazit

Der vorliegende Artikel hat einige interessante Neuerungen aus dem Bereich Java Development Tools (JDT) vorgestellt, die dieses Jahr im Rahmen des Helios-Release veröffentlicht wurden. Bahnbrechende Neuerungen sind auch in diesem Jahr nicht dabei, dennoch kann von Ideenmangel im JDT-Projekt nicht die Rede sein. Viele bekannte und bewährte Funktionen wurden noch weiter verfeinert (zum Beispiel die Erweiterungen in den Refactorings oder Instance Counts beim Debugging) und hier und da sind sogar ganz neue Funktionen hinzugekommen (zum Beispiel die On-/Off-Tags im Code-Formatter oder die Funktion zum Abkürzen von Package-Namen). Einen Überblick über sämtliche Neuigkeiten in der neuen JDT-Version findet sich in der mitgelieferten Hilfe (am besten auf der Willkommenseite den Link What’s New anklicken). Insgesamt bleibt daher der Eindruck, dass sich die Java-Entwicklungsumgebung Eclipse in der neuesten Version weiter verbessert hat und viele Entwickler einige der neuen Funktionen in Zukunft schätzen werden

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.