Welche Neuerungen sind mit Java 7 zu erwarten?

Läuft weiterhin alles nach Plan, hat das Warten auf die siebte Version der Java Standard Edition schon bald ein Ende: Am 28. Juli 2011 soll die Arbeit vieler Monate endlich abgeschlossen und Java 7 offiziell freigegeben werden. Als Zeichen des guten Willens gegenüber der Open-Source-Gemeinde hat sich der US-Konzern Oracle sogar dazu entschieden, Suns Java Development Kit durch OpenJDK als Referenzimplementierung zu ersetzen. Lassen Sie uns nun einen Blick auf einige weitere Änderungen werfen, die Java SE 7 mit sich bringen wird.

Auch wenn manch eine wünschenswerte Änderung auf Version 8 verschoben werden musste, hat der Java Community Process (JCP) mit seinen vielen Helfern offenbar wieder ganze Arbeit geleistet: Java soll performanter, offener und einfacher werden.

Performanter soll Java 7 vor allem durch den neuen Garbage First Garbage Collector (G1 GC) werden, der den veralteten Concurrent Mark-Sweep (CMS) ablösen wird. Mehr Offenheit will Oracle durch die neue Referenzimplementierung OpenJDK schaffen, deren Quellcode unter der GNU General Public License in Version 2 (GPLv2) veröffentlicht wird. Und einfacher soll die neue Version vor allem durch kleinere Änderungen der Programmiersprache selbst werden.

Nachfolgend betrachten wir, was Java 7 an Mehr haben wird.

Mehr Performance: Garbage First Garbage Collector (G1 GC)

Konnte man den neuen Garbage Collector G1 bereits in aktuellen Versionen von Java 6 experimentell durch den Befehl

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

einschalten, wird er in der kommenden Veröffentlichung nun endgültig zum Standard werden. Aber was genau macht ein Garbage Collector eigentlich?

Wer mit der Programmiersprache C arbeitet, wird früher oder später Speicher mit malloc() (engl.: memory allocate) allozieren müssen. Anschließend lassen sich die zugewiesenen Speicherbereiche verwenden, um Daten abzulegen und letztlich wieder mit free() freizugeben. Klingt einfach? Ist es eigentlich auch, aber allzu häufig passiert es dann doch, dass in einer komplexen Anwendung Speicherbereiche reserviert, jedoch nicht wieder freigegeben werden.

Das kann nicht nur speicherfressend sein, sondern auch ein Sicherheitsrisiko darstellen, wenn sensible Daten im Speicher hängen bleiben, die nur temporär gebraucht wurden. Solche Fehler wollte man mit Java, das (absichtlich) stark an C erinnert, endgültig vermeiden. Und dazu gibt es den Garbage Collector: Werden Objekte nicht länger gebraucht und liegen „tot“ im Speicher rum, räumt sie der GC in gewissen Abständen aus dem Weg.

Doch auch dieses Prinzip hat leider einen Haken: Um „tote“ Objekte zu finden und zu entsorgen, muss die Applikation kurzfristig angehalten werden. Man spricht daher auch vom Stop-the-World-Effekt. Zwar handelt es sich nur um wenige Millisekunden, aber in einer kritischen Systemkomponente können Pausen von über 100 ms manchmal eben schon zu lange sein.

Um dieses Problem zu lösen, geht der G1 GC mehrere Wege. Einerseits nutzt er moderne Hardware mit mehreren Prozessoren, um die Last zu verteilen und die Pausen zu verringern. Andererseits wird der Speicher in kleine Bereiche zerlegt, die schnell und regelmäßig umkopiert werden können, was Fragmentierung verhindern soll und zeitintensives Defragmentieren unnötig werden lässt.

Darüber hinaus soll der neue Garbage Collector G1 bessere Vorhersagen liefern, wie lange die Pausen maximal dauern werden. Zwar gibt es keine Garantie, dass dies funktioniert, aber zumindest eine gute Chance. Sollen Pausen nicht länger als 50 ms dauern, würde man dies wie folgt festlegen:

-XX:MaxGCPauseMillis=50

Mehr Offenheit: OpenJDK und das Da Vinci Machine Project

Als der Software-Konzern Oracle 2009 bekannt gab, dass er Sun Microsystems für mehrere Milliarden US-Dollar kaufen werde, löste das bei so manchem Anhänger der Open-Source-Gemeinde Besorgnis aus. Sun Microsystems war nicht nur bei Java federführend, sondern auch beim Office-Produkt Open Office und dem Betriebssystem Solaris. Mit der Wahl von OpenJDK als neue Referenzimplementierung für Java will Oracle einige Zweifel aus der Welt schaffen und verweist im hauseigenen Blog auf das Ziel eines offeneren „Java ecosystems“.

Darüber hinaus soll die Java Virtual Machine (JVM) HotSpot in der neuesten Version noch bessere Unterstützung für andere Sprachen wie Ruby, Python und Co. bieten. Dazu muss man wissen: In Java entwickelte Programme werden nicht wie üblich direkt in betriebssystem- und plattformspezifischen Maschinencode übersetzt, sondern in den sogenannten Bytecode.

Dieser in den Class-Dateien vorzufindende Bytecode wird letztlich von der JVM gestartet und erlaubt die viel gelobte Plattformunabhängigkeit. Nun ist es aber der virtuellen Maschine relativ egal, ob der Bytecode durch eine Java-, Ruby- oder Python-Datei erzeugt wurde, solange er der Spezifikation folgt und somit korrekt ausgeführt werden kann.

Und genau das machen sich Projekte wie JRuby und Jython zunutze. Mit Ruby und Python vertraute Programmierer können auf diesem Wege Code schreiben, der syntaktisch an Ruby und Python erinnert, aber letztlich Bytecode liefert, welcher wiederum durch die JVM plattformunabhängig gestartet werden kann.

Eigentlich eine Win-Win-Situation, oder? Leider gibt es wie so oft einen Haken: Java ist eine typisierte Sprache, Ruby, Python und andere Skriptsprachen sind jedoch häufig typenlos. Typisierte Sprachen verlangen, dass der Typ von Variablen bereits vor der Ausführung des Programms feststeht. Zur Laufzeit muss also bereits klar sein, ob eine Variable eine Zahl oder eine Zeichenkette beherbergen soll. Typenlose Skriptsprachen verzichten auf diese Unterscheidung und erlauben das Anlegen von Variablen, denen zur Laufzeit beliebige Werte übergeben werden können.

Bisher gibt es keine saubere Lösung für dieses Problem und alle Ansätze verschenken auf die eine oder andere Weise Performance. Dieser Herausforderung hat sich nun endlich das Da Vinci Machine Project angenommen und den Java Specification Request (JSR) 292 umgesetzt.

In diesem JSR wurde die Einführung der Bytecode-Instruktion invokedynamic angedacht, die dynamische Verlinkungen zur Laufzeit erlauben soll. Auf diesem Wege kann ein abstrakter Rahmen definiert werden, der erst während der Programmausführung eine konkrete Verlinkung mit konkreten Methoden verlangt. Und das Beste daran: Die Verlinkung kann sich – je nachdem, welche Methode gebraucht wird – während der Ausführung wieder verändern.

Auf diesem Umweg bietet die typisierte Sprache Java nun auch endlich einen Weg für typenlose Sprachen – und das ohne lästigen Performance-Verlust.

Mehr Einfachheit: Bessere Java-Syntax durch Project Coin

Für die Programmierer unter den Java-Nutzern bietet die siebte Version von Java dank Project Coin auch einige Änderungen, die sich viele sicher schon lange gewünscht haben. Allen voran der Klassiker, der nun endlich implementiert wurde:

Switch-Anweisungen mit Strings
Was eigentlich selbstverständlich sein sollte, verwundert Informatik-Studenten seit jeher: Mit dem Schlüsselwort switch lassen sich in Java (und anderen Sprachen) leider keine Zeichenketten vergleichen. Nun geht es endlich!

switch(answer)
{
   case "yes":
      //...
      break;
   case "no":
      //...
      break;
   default:
      //...
}

Unterstriche in Zahlenwerten
Um lange Ketten von Ziffern besser lesen zu können, erlaubt Java in Zukunft die Verwendung von Unterstrichen, die bei der Bytecode-Erzeugung einfach wieder ignoriert werden. So wird aus 1000000000 (1 Milliarde):

int one_billion = 1_000_000_000;

Verbesserte Type Inference
Unter dem wohlklingenden Namen Diamond wurde ein Feature in die Java-Syntax aufgenommen, welches das Arbeiten mit Generics spürbar erleichtern soll. So wird man in Zukunft statt

Map<String, List<String>> m = new HashMap<String, List<String>>();

einfach

Map<String, List<String>> m = new HashMap<>();

schreiben können. Warum doppelt, wenn es auch einfach geht?

Try-Catch-Anweisungen mit mehreren Exceptions
In Java 7 ist es nicht mehr notwendig, mehrere Exceptions, die das gleiche bewirken, einzeln abzufangen, was zu unnötig viel Code führt. Stattdessen lassen sie sich in einer einzigen Catch-Abfrage schnappen. Das könnte dann in etwa wie folgt aussehen:

try {
   //...
} catch (ExceptionA | ExceptionB | ExceptionC | ExceptionD e) {
   e.printStackTrace();
}

Das neue Interface AutoCloseable
Arbeitete man bisher mit Ressourcen, die es nach der Benutzung wieder zu schließen galt (z. B. einem InputStream), musste man darauf stets manuell achtgeben. Zumeist schloss man die Ressource via close() im Finally-Teil der Try-Catch-Anweisung. Das passiert nun automatisch, wenn die Klasse das neue Interface AutoCloseable implementiert. So braucht man in Zukunft statt

BufferedReader BR = new BufferedReader(new FileReader(path));

try
{
   return BR.readLine();
}
finally
{
   BR.close();
}

schlicht und ergreifend nur dieses bisschen Code:

try (BufferedReader BR = new BufferedReader(new FileReader(path)))
{
   return BR.readLine();
}

Neben den aufgezeigten Änderungen haben noch viele weitere kleine und große Verbesserungen ihren Weg in die neue Java SE 7 gefunden. So gibt es wieder neue Input/Output-APIs, mit denen sich Datei-, Verzeichnis- und Socket-Operationen noch einfacher realisieren lassen. Zudem sind die eher selten verwendeten Protokolle SCTP (Stream Control Transmission Protocol) und SDP (Sockets Direct Protocol) nun „out of the box“ verfügbar.

Mit solchen Aufzählungen könnte es nun sehr lange weitergehen und es fällt schwer zu sagen, welches Feature im Entwickleralltag wem den größten Nutzen bringen wird. Für eine komplette Liste empfiehlt sich ein Blick auf die offizielle Liste aller Neuerungen in Java 7 auf den Seiten des OpenJDK.

Fazit

Auch wenn am Ende nicht alle zunächst geplanten Verbesserungen in Java 7 Einzug erhalten haben und einige Erwartungen auf Version 8 vertröstet werden müssen, so ist dennoch klar, dass der kommende Release ein Erfolg sein wird.

Mit dem neuen Garbage Colletor G1 und einer besseren Unterstützung für typenlose Sprachen macht Java 7 einen deutlichen Performance-Sprung nach vorne. Die vielen kleinen Verbesserungen der Java-Syntax werden vor allem den Programmierern helfen, ihren Code noch leserlicher zu gestalten und so Zeit, Nerven und letztlich auch Kosten zu sparen.

Und wer noch immer nicht überzeugt ist, findet auf den Seiten des OpenJDK eine prall gefüllte Liste mit neuen Features, die selbst bei Skeptikern für Aha-Erlebnisse sorgen dürfte. 🙂

Weiterführende Informationen

Ihr neues Web-Projekt wird mit Java entwickelt? Sie möchten ein bestehendes Java-System erweitern oder eine Software-Plattform migrieren? Sie benötigen Schnittstellen zwischen Anwendungen im Unternehmen? //SEIBERT/MEDIA ist der richtige Partner. Wir legen größten Wert auf iterative Erweiterbarkeit, Performanz, Skalierbarkeit, Testbarkeit und Plattformunabhängigkeit und schaffen so individuelle High-End-Software-Lösungen, die sich auch im Nachhinein flexibel ausbauen und verändern lassen. Bitte sprechen Sie uns unverbindlich an!

Unsere spezielle Seite zum Thema Java-Entwicklung
Agile Software-Entwicklung mit //SEIBERT/MEDIA
Dynamische Web-Anwendungen: GWT im Projekteinsatz
Der StepStone-Bewerbungsgenerator: Technische Umsetzung in GWT


Mitwirkender an Konzeption und Umsetzung: Micha Kops
Bild: Javas Maskottchen von Mokund unter CC-Lizenz

Artikel teilen:Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someonePrint this page