Java 9 erst 2017

Software::Entwicklung

Ein halbes Jahr später als bisher geplant, am 23. März 2017, soll Java 9 erst erscheinen. Der Hauptgrund für die Verschiebung ist die Modularisierung der Sprache, die auf breites Interesse innerhalb der Java-Gemeinschaft stößt und deren Einzelheiten zum Teil immer noch intensiv diskutiert werden.

Von Hans-Joachim Baader

Oracle

Eigentlich sollte am 10. Dezember Schluss sein mit dem Hinzufügen von weiterer Funktionalität zu Java 9. Zu diesem Termin sollte die Stabilisierung der Software beginnen, für die neun Monate eingeplant waren. Am 22. September 2016 hätte Java 9 demnach fertig sein sollen.

Aus diesem Termin wird nun wohl nichts, denn wie Mark Reinhold, Chef der Entwicklungsabteilung der Java Standard Edition bei Oracle, jetzt bekannt gab, ist die Modularisierung der Sprache, das Projekt Jigsaw, noch nicht abgeschlossen. Laut Reinhold wurden zwar viele Teilschritte bereits erledigt, aber es steht noch der Entwurf des »Java Enhancement Proposals« (JEP) 376 aus. Dieses stieß auf breites Interesse und wertvolles Feedback der Java-Gemeinschaft, und Reinhold erwartet, dass die Diskussion noch andauern und weiteres Feedback eintreffen wird.

Auch um den Entwicklern der wichtigen Generierwerkzeuge und Entwicklungsumgebungen mehr Zeit zu geben, ihre Software an Java 9 anzupassen, schlägt Reinhold daher vor, die Frist für neue Funktionen auf den 25. Mai 2016 zu verschieben, die offizielle Freigabe auf den 23. März 2017. Das zusätzliche halbe Jahr solle idealerweise genutzt werden, um das Projekt Jigsaw zu komplettieren und die Qualität der anderen neuen Funktionalität zu optimieren. Aber auch gegen bisher nicht geplante neue Funktionalität sei nichts einzuwenden, solange sie kein übermäßiges Risiko für die endgültige Freigabe darstelle.

Sofern der Plan akzeptiert wird und nicht weiter verschoben werden muss, erschiene damit Java 9 rund drei Jahre nach Java 8. Das erscheint früh genug, da viele Entwickler noch gar nicht auf Java 8 aktualisiert haben dürften.

Die Liste der zu erwartenden Neuerungen von Java 9 ist recht weitreichend. JEP 102 zielt darauf ab, das API zu Systemprozessen zu verbessern. JEP 110 will einen HTTP 2-Client implementieren, JEP 143 die Geschwindigkeit steigern, indem Sperren im Code der Objekt-Monitore optimiert werden. JEP 197 ist ebenfalls eine Optimierung, die den Code-Cache im Hotspot-Compiler in Segmente aufteilt. Dazu kommen noch weitere Vorschläge für Optimierungen. JEP 198 fügt zu der Laufzeitbibliothek ein schlankes JSON-API hinzu. JEP 199 verbessert den »intelligenten« Compiler sjavac.

JEP 224 will Javadoc auf HTML5-Niveau heben. JEP 227 dagegen fordert die Aktualisierung von Unicode auf die Spezifikation 7.0 (oder jetzt möglicherweise 8.0). Daneben stehen weitere Compiler-Erweiterungen, eine Mikrobenchmark-Suite und eine Portierung auf 64-Bit-ARM-Prozessoren unter Linux auf dem Plan.

Am folgenreichsten aber ist zweifellos JEP 201, in dem der gesamte JDK-Quellcode modularisiert wird. Es ist eine Voraussetzung für JEP 200 »Modulsystem für JDK«, das für Java 9 so bedeutende Projekt Jigsaw, das Java mit einem stark verbesserten nativen Modulsystem ausstatten soll.

Projekt Jigsaw will das JDK selbst modularisieren, so dass es beispielsweise auf kleinen Rechnern zum Einsatz kommen kann, die nur einen Teil des gesamten JDK benötigen. Es soll die Sicherheit und Wartbarkeit der Java SE-Plattform erhöhen, die Anwendungen beschleunigen und auch die Entwicklung von Bibliotheken und Anwendungen erleichtern.

Java besitzt zwar bereits von Beginn an ein Modulsystem, das auf »Packages« beruht, doch das hat sich im Lauf der Jahre als nicht ausreichend erwiesen. So sind alle Packages öffentlich, auch wenn sie nicht extern genutzt werden sollten, und alle Abhängigkeiten sind statisch. Existierende Lösungen, die Abhängigkeiten flexibler oder auch optional machen und das Starten und Stoppen von Modulen zur Laufzeit ermöglichen, beispielsweise OSGi, sind komplex und nicht in das JDK integriert.