Die Neuerungen in Java 9
Starker Kaffee
Java 9 bringt eine Menge Neuerungen für Java-Entwickler. Das fängt bei dem langersehnten Modulsystem an und hört bei Performanceverbesserungen noch lange nicht auf.
Es hat doch noch geklappt: Seit dem 21. September dieses Jahres ist Java 9 offiziell verfügbar. Ursprünglich sollte die neue Java-Version bereits 2016 veröffentlicht werden, wurde dann aber immer wieder verschoben. Noch im Mai, also kurz vor dem zuletzt auf Ende Juli 2017 angesetzten Release-Termin, erzwangen Diskussionen um das neue Java Platform Module System (JPMS) eine Verschiebung auf September.
Mit Project Jigsaw hat es das langersehnte Modularisierungskonzept aber doch noch in den Java-9-Kern geschafft. Ursprünglich war seine Veröffentlichung bereits mit Java 7 vorgesehen, man entschied sich jedoch aufgrund der tief greifenden Änderungen im JDK und des daraus folgenden Testaufwands für einen Aufschub. Zwischenzeitlich stand sogar die Veröffentlichung mit Java 9 auf der Kippe, als das Exekutiv-Komitee des Java Community Process (JCP) im Mai gegen die Spezifikation stimmte und damit eine erneute Überarbeitung erreichte. Inzwischen haben sich 24 von 25 Stimmen für die überarbeitete Version ausgesprochen; Red Hat hat sich der Stimme enthalten.
Modularisierung war in der Java-Welt stets ein Thema. Bisherige Ansätze unterstützten zwar schon eine gewisse Modularität, konnten vielen Ansprüchen jedoch nicht genügen. So stieß die Kombination von Modulen in Form von JARs aufgrund strenger Abhängigkeiten untereinander immer wieder an ihre Grenzen. Problematisch wurde es spätestens, wenn mehrere JARs in unterschiedlichen Versionen in den Classpath eingebunden wurden (die sogenannte JAR-Hell): Der Classloader wählt dann stets die zuerst gefundene Version und ignoriert alle anderen. Aufgrund des dadurch entstehenden Zufallsmoments konnte es vorkommen, dass zur Kompilierzeit keinerlei Probleme auftreten, zur Laufzeit allerdings schon.
Project Jigsaw: Java wird modular
Die Modularisierung mit Jigsaw soll diese Probleme beheben. Das Projekt verspricht eine bessere Skalierbarkeit, erhöhte Sicherheit und Wartbarkeit, gesteigerte Performance und eine einfachere Erstellung und Wartung größerer Bibliotheken und Anwendungen. Details dazu finden Sie im nachfolgenden Artikel.
Die Jigsaw-Integration wird unter dem JDK Enhancement Proposal (JEP) 261 geführt, den man wie alle JEPs unter openjdk.java.net/jeps nachlesen kann. Er unterteilt sich in drei wesentliche Arbeitspakete:
1. Im JEP 200 („The Modular JDK“) geht es um die modulare Struktur des JDK. Dieses wird in einzelne Module aufgespalten, die sich zur Kompilier-, Build- und Installationszeit kombinieren lassen. So kann man reduzierte Laufzeitumgebungen erstellen.
2. Der JEP 201 („Modular Source Code“) beschreibt die Reorganisation des Quellcodes des JDK und die daraus folgende modularisierte Struktur. Das verbesserte Build-System bietet Unterstützung für die kompilierfähigen Module. Hierdurch werden saubere Modulgrenzen erzwungen. Das neue Strukturierungsschema sieht Modulgrenzen auf oberster Ebene des Quellcodebaums vor.
3. Ziel des JEP 220 („Modular Run-Time Images“) ist die Modularisierung von Laufzeit-Images für das JDK und das JRE. Durch die Umstrukturierung ändert sich die interne Verzeichnisstruktur der Java Standard Edition (SE). Das bisherige JDK-Build-System erzeugte zwei Arten von Laufzeit-Images: die JRE, eine komplette Implementierung von Java SE, und das JDK, das die JRE und weitere Entwicklungswerkzeuge enthält. Diese Aufteilung besteht bereits seit Java 2 und wurde seitdem nicht mehr verändert. Durch die Restrukturierung entfällt die Unterscheidung und es gibt nur noch das JDK-Laufzeit-Image.
Eine zuverlässige Konfiguration der Abhängigkeiten soll die Schwächen des bisherigen Classpath-Konzeptes ersetzen und den Weg weg von den bisher eingesetzten JARs ebnen, um so Zeit- und Speichereffizienz zu steigern. Durch die verbesserte Isolation der Module werden teils bisher öffentlich zugängliche APIs außerhalb des eigenen Moduls nicht mehr nutzbar sein. Bislang waren alle als public deklarierten Klassen eines JAR auch allen anderen JARs zugänglich. Nach dem neuen Konzept ist nun ein expliziter Export nötig (mehr dazu im folgenden Artikel). Gründliche Tests sollen negative Seiteneffekte dieser Änderung vermeiden, ganz ausgeschlossen sind Probleme in der Praxis jedoch nicht.