Das Modulsystem Jigsaw in Java 9
In Einzelteile zerlegt
Das neue Modulsystem Jigsaw bringt Java die dringend gewünschte Modularisierung. Die Änderungen sind umfassend und betreffen Plattform, Sprache, Ökosystem – und eigene Java-Projekte.
Java ist über 20 Jahre alt. Seitdem ist die Plattform stark monolithisch gewachsen, und eine Menge unerwünschter Abhängigkeiten sind entstanden. Solche Altlasten soll Jigsaw beseitigen, indem die Plattform aufgeräumt und modularisiert wird. Dabei wollten die Java-Architekten aber nicht haltmachen, stattdessen wollen sie auch die Modularisierung von Anwendungen unterstützen: Entwickler strukturieren schon lange ihre Anwendungsarchitektur in fachliche und technische Komponenten, um sie übersichtlicher und wartbarer zu machen. Java bot dafür bisher keine direkte Unterstützung, weswegen man zum Beispiel auf Package-Namenskonventionen oder auf externe Tools wie Maven oder OSGi zurückgegriffen hat.
Jigsaw erlaubt nun die native Modulbildung innerhalb der Sprache selbst und verfolgt dabei vor allem drei Ziele:
– Reliable Configuration: Der fehleranfällige Classpath soll abgelöst werden. Wenn eine Klasse mehrfach (z. B. in mehreren JARs) darauf enthalten ist, entscheidet bisher allein die Suchreihenfolge, welche Instanz der Klasse benutzt wird. Das soll durch explizite Modulabhängigkeiten und den neuen Module Path verbessert werden.
– Strong Encapsulation: Ein Jigsaw-Modul definiert seine öffentliche Komponenten-API. Andere Module haben keinen Zugriff auf nicht öffentliche Klassen.
– Scalable Platform: Die modularisierte Java-Plattform ermöglicht, angepasste, schlankere Runtime-Images für eine Anwendung zu bauen und nur auszurollen, was diese wirklich benötigt.
Ein Blick zurück
Die Einführung von Modulen in Java hat eine lange Historie: Im Java Specification Request (JSR) 277 wurde schon 2005 begonnen, ein natives Modulsystem in Java zu etablieren. Es sah unter anderem Modulversionierung und -Repository vor, kam aber nie über den Draft-Status hinaus und ist seit Sommer 2016 zurückgezogen (zusammen mit dem JSR 294). Das neue Modulsystem Jigsaw wurde 2008 angekündigt, danach aber mehrfach verschoben, vor allem weil sich die Modularisierung des JDK als komplexe Aufgabe herausstellte. Das Project Jigsaw wird im JSR 376 spezifiziert und umfasst Teilaktivitäten rund um die Java-Spracherweiterung sowie Aktivitäten rund um die Plattformmodularisierung, worunter auch die Reorganisation des Java-Quellcodes, die Definition der Plattformmodule sowie die Kapselung interner APIs fallen.
Verschiedene Java Enhancement Proposals (JEPs 200, 201, 220, vor allem aber 260, 261 und 282) treiben die Entwicklung voran. Seit Anfang 2016 ist Jigsaw in den Java 9 Early Access Builds integriert. Im Dezember 2016 wurde der Meilenstein „Feature Extension Complete“ erreicht, Anfang Februar dann auch „All Tests Run“. Anfang Mai stimmte die Mehrheit des Executive Committee (EC) des Java Community Process (JCP) gegen das Modulsystem in seiner damaligen Form. Die Entscheidung erzwang eine Verschiebung der eigentlich für Juli geplanten Veröffentlichung von Java 9. Unternehmen wie IBM, Red Hat und SAP kritisierten dabei vor allem, dass das Java Platform Module System (JPMS) zwar gut für die Modularisierung von Java selbst funktioniert habe, aber für viele Java-Anwendungen problematisch sei. Die zuständige Expertenrunde erarbeitete daraufhin einige Korrekturen der Spezifikation, die die Kompatibilität mit dem Build-System Maven verbessern und die strikte Kapselung in Java 9 standardmäßig aufweicht (JVM-Schalter --illegal-access=permit).
Der nun doch mögliche Zugriff auf interne APIs soll bestehenden Java-Anwendungen die Zusammenarbeit mit dem neuen Modulsystem erleichtern. Kommende Java-Versionen sollen dann die strikte Kapselung umsetzen (--illegal-access=deny). Ende Juni nahm das EC mit 25 Jastimmen und einer Enthaltung den JSR 376 an, sodass Java 9 nun mit Modulsystem veröffentlicht werden kann.
Jigsaw versus OSGi
Das hinter OSGi stehende Industriekonsortium hat schon 2000 eine Spezifikation eines Java-basierten Modulsystems eingeführt. Wie unterscheiden sich die beiden Technologien?
– In OSGi werden Komponenten als OSGi-Bundles über Classloader-Mechanismen gekapselt, um Klassen vor externem Zugriff zu schützen. Das lässt sich jedoch umgehen. In Jigsaw ist eine strikte Kapselung tief in der Plattform verankert, auch wenn sie bei Java 9 noch nicht erzwungen wird.
– OSGi unterstützt Komponentenversionierung. Jigsaw kennt eine solche Versionierung von Modulen nicht, was stark kritisiert wird: Die Jigsaw-Spezifikation klassifiziert Versionierung ausdrücklich als Nichtanforderung und benennt das als Aufgabe für Build-Werkzeuge. Eine Modulversion in Jigsaw kann nur als zusätzliches Meta-Attribut mitgegeben werden, das die Java-Plattform nicht auswertet. Insbesondere ist es ohne fortgeschrittene Strukturen wie Layer per se nicht möglich, mehrere Versionen eines Moduls gleichzeitig zu verwenden. Das hat die JPMS-Expertengruppe inzwischen als Problem benannt, seine Lösung jedoch auf eine spätere Java-Version verschoben.
– Außerdem haben Jigsaw-Module, anders als OSGi-Bundles, keinen Lebenszyklus: Sie lassen sich zur Laufzeit also nicht starten oder stoppen.