JDT Entdeckertour: Eclipse Juno

Java Development Tools: Alles gleich, doch vieles anders

Marc Teufel
©Shutterstock/gonin

Im Rahmen des Eclipse Juno Release 2012 kamen große Veränderungen auf die Nutzergemeinde zu. Der Versionszähler der Plattform sprang auf die 4, und ein neuer zeitgemäßer Unterbau sollte den alten langsam ablösen. Doch auch wenn sich vieles um die neue Eclipse-Plattform drehte, so haben sich auch die Java Development Tools abermals verbessert.

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

Lange habe ich überlegt, welchen Titel ich für diesen JDT-Artikel nehme. In einer relativ kurzen Überschrift die Entwicklung zu erfassen, die in den letzten Jahren stattgefunden hat und welche nun im Rahmen des Juno-Release erstmalig in großem Umfang zum Tragen kommt, ist nicht ganz einfach. Betrachtet man die Entwicklung der letzten zwei Jahre, stellt man nämlich fest, dass die Entwicklung weniger im Bereich Java Development Tooling, sondern mehr auf der Eclipse-Plattform stattgefunden hat. Im Jahr 2012 springt der Versionszähler von Eclipse von 3.8 auf 4.2, was auf große Veränderungen schließen lässt. Und tatsächlich, 2012 erfolgte endlich der Umstieg auf die neue Eclipse-4-Plattform, früher auch bekannt unter dem Decknamen „e4“. Und auch wenn mit dem Wechsel in die neue moderne Generation große Veränderungen in der Struktur und Entwicklung von Eclipse-Anwendungen verbunden sind, so blieb für Entwickler, die Eclipse als Java-Entwicklungsumgebung verwenden, kurioserweise erst einmal alles beim Alten. Der Grund hierfür liegt in den Unterschieden zwischen alter und neuer Plattform. Der Wechsel kann beziehungsweise konnte daher nicht einfach so von heute auf morgen stattfinden, es gibt einfach zu viele Nutzer, die ihre komplette Anwendungsentwicklung auf Basis von Eclipse und seiner Rich Client Platform betreiben.

Aus diesem Grund lieferte die Eclipse Foundation 2012 zusammen mit dem neuen Eclipse 4 auch einen Kombatibilitätsmodus, mit dem es möglich wurde, Eclipse-3.x-Anwendungen auf der neuen Plattform laufen zu lassen und sanft zu migrieren. Dass dieses Konzept gut funktionierte, bewies das JDT-Team bei Eclipse in eindrucksvoller Weise, denn die Java IDE von Eclipse wurde damals noch nicht auf Eclipse 4 portiert, sondern nutzte den Compatibility Layer, um sowohl im 3.x-Stream als auch in der neuen Umgebung lauffähig zu sein. Aus diesem Grund bleibt im Zusammenhang mit der Java-Entwicklungsumgebung Vieles beim Alten. Im Bereich Java Tooling selbst hat sich in den Monaten vor dem Juno Release aber auch wieder einiges getan. Neben der Unterstützung für Java 7, die bereits länger verfügbar war und natürlich auch im Juno Release enthalten ist und weiter verbessert wurde, lassen sich die neuen Funktionen vor allem den Bereichen Java-Editor und -Compiler zuordnen.

Java-Editor

So sind im Java-Editor einige kleinere Neuigkeiten hinzugekommen, die das Leben des Java-Entwicklers wieder ein Stück angenehmer gestalten. Quick Outline und Quick Hirarchy sind zwei gern genutzte Werkzeuge, die über die Tastenkombination CTRL+O beziehungsweise CTRL+T aufgerufen werden können. Sie leisten bereits seit Jahren gute Dienste, insbesondere wenn es darum geht, sich einen Überblick über eine Java-Klasse zu verschaffen. Gerne benutzt man diese gelben Fenster auch, um mittels Cursortasten schnell zu einer bestimmten Stelle im Quelltext zu navigieren. Hat man es mit umfangreichen Klassen zu tun, kann allerdings auch hier die Darstellung lang und unübersichtlich werden. Aus diesem Grund haben die Entwickler den bereits bestehenden Filter dahingehend erweitert, dass nun Camel Case unterstützt wird.

Die zahlreichen Quick Assists in Eclipse, die man über die Tastenkombination CTRL+1 aktivieren kann, helfen schon lange beim Schreiben und Umschreiben von Code. Das diesjährige JDT-Release hat auch an dieser Stelle wieder zwei neue interessante Quick Assists im Gepäck. Sie helfen im Zusammenhang mit foreach-Schleifen. In den allermeisten Fällen iteriert man bei einer foreach-Schleife durch eine Liste von Objekten, zum Beispiel durch Strings. Will man nun statt einer foreach- eine klassische for-Schleife haben, kommen die beiden neuen Quick Assists „Convert to indexed for Loop“ und „Convert to Iterator-based for Loop“ ins Spiel. Der Grund, warum gleich zwei Quick Assists hierfür angeboten werden, ist schnell erklärt: Eine for-Schleife, die auf einer Liste von Objekten iteriert, kann man in Java entweder mithilfe einer Hilfsvariable bauen oder man kann auf Basis eines Iterators durch die Liste navigieren, wobei ein Iterator als Zeiger dient und praktisch in jeder Java-Collection-Klasse vorhanden ist. Die beiden bereits angesprochenen neuen Quick Assists sind also in der Lage, eine foreach-Schleife entweder indexbasiert mit Hilfsvariable oder auf Basis des Iterators in eine klassische for-Schleife zu konvertieren. Listing 1 zeigt, wie eine typische foreach-Schleife nach Anwendung der beiden neuen Quick Assists aussehen kann.

public void processStrings(List<String> strings) {

   // Original foreach-Schleife
   for (String string : strings) {
  
   }

   // Convert to indexed 'for' loop
   for (int i = 0; i < strings.size(); i++) {
      String string = strings.get(i);
   }

   // Convert to Iterator-based 'for' loop
   for (Iterator<String> iterator = strings.iterator(); iterator.hasNext();) {
      String string = iterator.next();
   }

}

Ein weiteres interessantes Hilfsmittel, das die Java Development Tools anbieten, wenn man beispielsweise länger auf einem Methodenaufruf oder auf einem Objekt verweilt, ist der so genannte „JavaDoc Hover“. Er zeigt Hintergrundinformationen über das gerade selektierte Element an. Im aktuellen Release ist nun eine Erweiterung enthalten, damit Annotationen auf Methodenparametern endlich korrekt angezeigt werden.

Umgang mit geschweiften Klammern

Hierbei handelt sich im Kern um einige neue Funktionen, die eigentlich recht einfach gestrickt sind, sich aber beim täglichen Programmieren als ziemlich effizient erweisen können: der optimierte Umgang mit geschweiften Klammern. Der Java-Editor verfügt eigentlich seit Längerem über die Möglichkeit, visuell darzustellen, welche geschweiften Klammern im Quelltext zusammengehören. Setzt man den Cursor beispielsweise ans Ende einer Methode, also hinter die schließende Klammer, wird die öffnende Klammer grau umrahmt dargestellt. Dieses Verhalten konnte man bisher in den Preferences auf der Seite Java | Editor an- und ausschalten. Mit der aktuellen JDT-Version ist es nun möglich, dieses Feature viel feingranularer einzustellen. Zunächst kann man weiterhin über die Option Bracket Highlighting grundsätzlich bestimmen, ob das Markieren der geschweiften Klammern erfolgen soll oder nicht. Dann gibt es drei zusätzliche, neue Optionen, um die Darstellung im Detail zu beeinflussen: Matching Bracket, Matching Bracket and Caret Location und Endclosing Brackets. Die erste Option ist die Standardeinstellung und sorgt dafür, dass wenn der Cursor vor oder hinter einer Klammer steht, lediglich die jeweils korrespondierende Klammer angezeigt wird. Die zweite Option sorgt dagegen dafür, dass nicht nur die korrespondierende Klammer, sondern sowohl öffnende als auch schließende Klammern markiert werden, sobald der Cursor vor oder hinter einer der beiden Klammern steht. Und die dritte und wahrscheinlich auch interessanteste Option (Enclosing Brackets) markiert konstant beide Klammern, zwischen denen sich der Cursor gerade befindet. Das hat zur Folge, dass öffnende und schließende Klammern einer Methode hervorgehoben werden und auch markiert bleiben, solange sich der Cursor in einer Methode befindet. Enthält die Methode ein if-Statement, eine Schleife oder ein ähnliches Konstrukt, das seinerseits wieder durch Klammern begrenzt ist, und der Cursor befindet sich in einem solchen Bereich, werden dessen Klammern hervorgeholt.

Schon vorhanden war der Befehl Navigate | Go to | Matching bracket beziehungsweise die Tastenkombination Shift+Ctrl+P. Wenn der Cursor vor oder hinter einer geschweiften Klammer steht und man aktiviert diesen Befehl, navigiert der Java-Editor automatisch zur korrespondierenden Klammer. Diese Funktion scheint in der Vergangenheit allerdings nicht an jeder Stelle im Editor sauber funktioniert zu haben. Die JDT-Entwickler versprechen an dieser Stelle, dass das nun durchgängig funktioniert. Mehr noch, durch erneutes Drücken der Tastenkombination Shift+Ctrl+P gelangt man nicht nur zur korrespondierenden Klammer, sondern umgekehrt auch wieder zurück. Somit erhält man eine weitere Möglichkeit, schnell im Quelltext hin- und herzuspringen.

Zu guter Letzt ist im Zusammenhang mit geschweiften Klammern noch eine weitere Neuerung erwähnenswert, mit der man Blöcke recht gut markieren kann. Positioniert man den Cursor nämlich hinter eine schließende Klammer und verweilt mit der Maus einen Augenblick darauf, wird der komplette Block in einer Art Tooltip sichtbar. So kann man sofort erkennen, wie umfangreich dieser Block ist.

Eigene Quick Fixes und Quick Assists für JDT schreiben

JDT bringt bereits eine große Anzahl von Quick Fixes und Quick Assists mit, die beim Schreiben von Code helfen. Selbstverständlich kann man hier auch eigene Beiträge leisten, indem man die Extension Points org.eclipse.jdt.ui.quickFixProcessors beziehungsweise org.eclipse.jdt.ui.quickAssistProcessors verwendet. Bei der Implementierung müssen allerdings einige Regeln beachtet werden: Es sind bestimmte Interfaces zu implementieren und Aktionen auszuführen die letztendlich zu einem Korrekturvorschlag oder zu einer Veränderung des Quellcodes führen. Speziell im Zusammenhang mit Quick Fixes und Quick Assists haben sich mit dem aktuellen JDT-Release hier einige interne Erweiterungen und Veränderungen ergeben. Unter [1] findet der interessierte Leser eine Beschreibung, welche Veränderungen das im Detail sind und wie man einen eigenen Quick Fix beziehungsweise Quick Assist auf Basis der aktuellen JDT entwickelt.

Optimiertes Anzeigen von „.class“-Dateien

Das Anzeigen von Java-Quellcode mit Eclipse ist kein Problem. Kein Wunder, dafür wurden die Java Development Tools ja auch gemacht. Doch was macht Eclipse, wenn man eine .class-Datei statt einer .java-Datei im Editor aufmachen will? Für den Fall, dass der Java-Quellcode dieser Klasse irgendwo (zum Beispiel in Form eines Source Attachments) im Zugriff ist, wird dieser herangezogen und angezeigt. Doch wenn kein Quelltext verfügbar ist, zeigt Eclipse standardmäßig eine eher magere Klassenübersicht an. Diese Übersicht wird on the Fly generiert und dann mit dem in Eclipse enthaltenen Class File Viewer angezeigt. Wem das zu wenig ist, der kann nun in den Preferences auf der Seite General | Editors | File Accociations auf den neu hinzugekommenen File-Typ *.class without source zurückgreifen und einen alternativen Editor definieren, der verwendet werden soll, wenn auf eine .class-Datei zugegriffen wird, für die jedoch keine Quellen vorliegen. So ist es nun auch kein Problem mehr, statt des Class File Viewers einen Java Decompiler wie JadClipse einzubinden, um Quellcode on the Fly zu erzeugen und anzuzeigen.

Java-Compiler

Ein weiteres wichtiges Betätigungsfeld, in dem Jahr für Jahr verbessert und ausgebaut wird, ist der in JDT enthaltene Java-Compiler. So sind auch hier wieder einige Neuerungen hinzugekommen, von denen ein paar in den folgenden Abschnitten erwähnt werden sollen. Im Zusammenspiel mit Java 7 hat man zum Beispiel den Umgang mit dem neuen try-with-resources-Konstrukt weiter verbessert. Eclipse kann nun erkennen, wenn ressourcenbehaftete Objekte vom Typ java.lang.AutoCloseable im Quellcode zwar geschlossen, aber nicht im Rahmen von try-with-ressources verwendet werden. Überhaupt ist der ganze Umgang mit Ressourcen und vor allem Resource Leaks deutlich besser und intelligenter geworden. Ist die entsprechende Option in den Preferences auf der Seite Java | Compiler | Error/Warnings aktiviert, dann weist Eclipse automatisch darauf hin, wenn eine Ressource geöffnet, aber nicht geschlossen wurde. Um zu erkennen, ob es sich bei einem nicht geschlossenen Objekt um eine Ressource im eigentliche Sinne handelt, geht Eclipse bei der Analyse davon aus, dass alle Klassen, die java.lang.AutoCloseable (ab Java 7) beziehungsweise java.io.Closeable (vor Java 7) implementieren, auch geschlossen werden müssen.

Enums und switch

Den Umgang mit Enums innerhalb eines switch-Konstrukts erleichtern einige neue Compilereinstellungen in den Preferences. Verzweigt man in einem switch auf Basis eines Enums und man vergisst den default-Zweig, kann Eclipse nun so eingestellt werden, hier eine Warnung auszugeben. Hierzu gibt es auf der Preference-Seite Errors/Warnings in der Rubrik Potential programming problems die neue Option switch is missing default case. Sie ist in der Standardeinstellung deaktiviert. Eclipse hat im Zusammenspiel von Enum und switch jedoch noch mehr zu bieten. Verzweigt man auf Basis eines Enum und man vergisst einen case-Zweig für eines der Enum-Werte, erinnert Eclipse mit einer Warnung, dass ein potenzieller case fehlt. Verantwortlich hierfür ist die neue Compileroption Icomplete switch cases on enum. Sie ist in der Standardeinstellung auf Warnhinweis eingestellt. Wäre ein default-Zweig vorhanden, wird erst einmal keine Warnung mehr angezeigt, wenn ein bestimmter case-Zweig fehlt. Will man trotzdem wissen, welche case-Zweige fehlen, obwohl ein default-Zweig vorhanden ist, aktiviert man in den Compileroptionen zusätzlich die Checkbox „Signal even if default case exist“.

Annotationsbasierte Null-Analyse

Das diesjährige JDT-Release bringt nicht nur Verbesserungen und Erweiterungen in bestehender Funktionalität, sondern hat mit der so genannten „annotationsbasierten Null-Analyse“ sogar ein ganz neues Feature an Bord. Es bedeutet an dieser Stelle, Regeln festzulegen, damit schon beim Schreiben von Quellcode festgestellt werden kann, wo Null-Werte erlaubt sind und wo nicht. Hierzu werden spezielle Annotationen verwendet, um Klassen, Methoden oder Methodenparameter zu markieren und auf diese Weise festzulegen, ob diese null sein können. Eclipse JDT bringt hierzu bereits Default-Implementierungen dieser Markerannotationen mit: @NonNull, @Nullable und @NonNullByDefault. Diese Standardmarker befinden sich im neuen Plug-in org.eclipse.jdt.annotation im Plug-in-Verzeichnis der Eclipse-Installation. Alternativ kann man auch eigene Annotationen einbinden, muss dann aber sicherstellen, dass sich diese im Java Build Path des Java-Projekts befinden, in dem sie verwendet werden. Außerdem müssen sie in den Preferences auf der Seite Java | Compiler | Errors/Warnings | Null Analysis bekannt gemacht werden (Abb. 1 und 2). Zu guter Letzt muss die annotationsbasierte Null-Analyse auf der gleichen Einstellungsseite (Abb. 1) aktiviert werden. Im Ursprungszustand ist diese neue Funktion nämlich abgeschaltet. Ist die annotationsbasierte Null-Analyse aktiviert und man reichert Quelltext nun mit den besagten Annotationen an, wird JDT eine ständige Diagnose durchführen und mitteilen, wenn gegen eine der Regeln verstoßen wird, die durch die Annotationen (@NotNull, …) aufgestellt werden.

Abb. 1: Für die annotationsbasierte Null-Analyse gibt es viele Einstellungsmöglichkeiten

Abb. 2: Bei Bedarf können eigene Annotationen für die Null-Analyse verwendet werden

Alle Elemente, die mit @Nullable markiert sind, dürfen null sein. Demgegenüber können die Objekte, die mit @NonNull markiert sind, nicht null sein. Setzt man @NonNullByDefault auf ein Package, eine Klasse oder eine Methode, werden alle darunter liegende Elemente automatisch mit @NonNull versehen. Listing 2 zeigt ein paar Beispiele für die Verwendung von @Nullable und @NonNull. Die Methode foo ist so deklariert, dass man kein null übergeben darf. In der Methode bar wird allerdings versucht, foo mit null aufzurufen. JDT erkennt das und gibt einen entsprechenden Hinweis aus. Auch bei Zuweisungen prüft Eclipse auf null, wie man in der Methode bar in Listing 2 sehen kann. Beide String-Zuweisungen sind nicht erlaubt, Eclipse wird das bemerken. Listing 3 zeigt den Umgang mit @NonNullByDefault. Da diese Klasse auf oberster Ebene mit @NonNullByDefault gekennzeichnet wurde, sind alle Elemente darunter automatisch Non-Null. Die beiden @NonNull-Annotation in der Methode foo sind somit redundant und nicht mehr erforderlich. Das Listing zeigt am Beispiel der Methode bar außerdem, wie man erreichen kann, dass einzelne Methoden von der globalen Annotation ausgenommen werden.

public void foo(@NonNull Object o) {
   System.out.println(o.toString());
}

@NonNull Object bar(@Nullable String s) {
   foo(null);
   @NonNull String myString = null;
   @NonNull String anotherString = s;
   return null;
}
@NonNullByDefault
class MyClass {
   public @NonNull Object foo(@NonNull Object o) {
      return o;
   }

   @NonNullByDefault(false)
   Object bar(Object o) {
      return o:
   }
}

Man sieht, mithilfe der annotationsbasierten Null-Analyse kann man schon beim Entwickeln etwaige durch Null-Werte verursachte Probleme erkennen und reagieren. Ferner wird die Codequalität gesteigert. Im Zusammenhang mit dieser neuen Funktion gibt es außerdem noch eine ganze Reihe weiterer Schalter und Einstellungen, mit denen man das Verhalten und die Meldungen, die Eclipse bei der Diagnose ausgibt, beeinflussen kann. Hierzu empfiehlt es sich, einen Blick in die JDT-Dokumentation (Stichwort „What‘s new“) zu werfen. Hier befinden sich wertvolle Hinweise. Da es sich bei der annotationsbasierten Null-Analyse um eine neue Funktion handelt, darf man davon ausgehen, dass hier in Zukunft noch weitere Verbesserungen und Erweiterungen folgen werden. Insbesondere plant das JDT-Team, hier noch mehr Quick Fixes einzuführen.

Zusammenfassung

Jedes Jahr das Gleiche. Die Entwickler des Java Development Tooling (JDT) überraschen mit neuen Funktionen, die das Programmieren von Java-Anwendungen mit Eclipse einfacher, schneller und angenehmer machen. Und auch wenn sich im Jahr 2012 alle Augen auf die neue Plattform richten, ist im Bereich JDT wieder einiges hinzugekommen. Neben den vielen kleinen Verbesserungen sind hier insbesondere die neuen Funktionen rund um die annotationsbasierte Null-Analyse hervorzuheben.

Aufmacherbild: green binary digits with light streaks von Shutterstock / Urheberrecht: gonin

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.