1.5Auf Java 7/8-Syntax mit NetBeans und Eclipse migrieren 

Wer eine große Codebasis auf Java 8 oder Java 7 migrieren möchte, steht vor dem Problem, wie das ohne großen manuellen Aufwand funktionieren kann. Als Erstes steht die Umsetzung auf die neuen Syntax-Möglichkeiten an. Das ist ein echter Mehrwert, und hier können moderne Entwicklungsumgebungen einiges als Vorarbeit leisten. Bei den Bibliotheken gibt es keine automatische Umsetzung von Alt nach Neu, hier ist leider Handarbeit angesagt.

Schauen wir uns an, welche Möglichkeiten die modernen IDEs bieten.

 

1.5.1Java 8-Syntax-Migration mit NetBeans 

Die aktuelle NetBeans-IDE bringt einen Code-Transformator mit, der elegant die Codebasis durchsucht und Transformationen automatisch durchführt. Das Menü Refactor bietet den Unterpunkt Inspect and Transform…, der zu einem Dialog führt:

Abbildung 1.2Transformationen in Java 8/Java 7 anstoßen

Unter Manage… öffnet sich ein weiterer Dialog, bei dem JDK Migration Support aktiviert ist und einige Änderungen voreingestellt sind; neu für Java 8 ist Convert to Lambda or Method References. Auch die Transformationen in die neue Java 7-Syntax sind voreingestellt, aktiviert werden kann: Can use Diamond, Convert to try-with-resources, Join catch sections using mulitcatch, Use specific catch und Use switch over Strings when possible.

Abbildung 1.3Einstellungsmöglichkeiten

Wer Programmcode neu mit NetBeans schreibt, wird gleich auf die neue Syntax hingewiesen. Vervollständigungen nutzen ganz natürlich zum Beispiel den Diamond-Operator.

 

1.5.2Java 8-Syntax-Migration mit Eclipse 

Seit der Version Eclipse 4.4 (bzw. Eclipse 4.3.2 mit Feature Pack für Java 8-Erweiterung) integriert die IDE einen Code-Transformator, der Klassenimplementierung von funktionalen Schnittstellen in Lambda-Ausdrücke verkürzen kann. Diese Transformationen sind über die Quick-Fixes/Quick-Assists möglich.

Abbildung 1.4Konvertierung in Lambda-Ausdruck

Leider kann diese Umsetzung (bisher) nicht für ein ganzes Projekt erfolgen und keine umfangreiche Codebasis komplett und automatisch auf die neuen Lambda-Ausdrücke gebracht werden.

 

1.5.3File-Klassen auf NIO.2 umstellen 

Um sich von der Klasse java.io.File zu lösen und in Richtung Path zu migrieren, ist Handarbeit angesagt. Zunächst gilt es, alle Stellen zu finden, die im Workspace oder Projekt die Klasse File referenzieren. Am einfachsten ist es, eine Anweisung wie File f; in den Code zu setzen, dann zum Beispiel in Eclipse (Strg) + (ª) + (G) zu aktivieren. Es folgt eine Liste aller Vorkommen. Diese Liste muss nun abgearbeitet werden und der Code auf NIO.2 konvertiert werden. Nicht immer ist es so einfach

in

umzusetzen oder

in

Eine andere Stelle, an der Konvertierungen möglich sind, betreffen FileReader und FileWriter. Diese Klassen sind gefährlich, weil sie standardmäßig die im System voreingestellte Kodierung verwenden. Eine Kodierung (wie UTF-8) im Konstruktor explizit vorzugeben ist jedoch nicht möglich. NIO.2 bietet eine bessere Methode, um an einen Reader/Writer aus einer Datei zu kommen, wobei in Java 8 Entwickler auch nicht gezwungen werden, diese Kodierung immer sichtbar anzugeben, denn das ist optional, ohne Angabe ist UTF-8 voreingestellt.

Tabelle 1.15Beziehen eines Dateistroms klassisch und mit NIO.2

Der Quellcode wird erst einmal länger, doch der Gewinn ist, dass die Kodierung nicht verschwindet und auch die Ein-/Ausgabe gleich gepuffert ist. Freunde der statischen Import-Anweisung komprimieren weiterhin zu Anweisungen wie:

Es ist auf jeden Fall manuelle Arbeit angesagt. Eigene Blöcke, etwa zum Schreiben in Dateien, können komplett zusammengestrichen werden auf einfache Methodenaufrufe wie: