Java 9 Modularität

Vorwort

Was ist Modularität in Java? Für die einen ist es ein Prinzip für die Entwicklung: auf Schnittstellen programmieren und die Details der Implementierungen verstecken. Das ist die Schule der Verkapselung. Für die anderen geht es darum, sich auf Klassenlader zu stützen, um dynamische Ausführungsumgebungen zu schaffen. Das ist die Schule der Isolation. Für wieder andere geht es um Artefakte, Repositories und Werkzeuge. Das ist die Schule der Konfiguration. Für sich genommen sind diese Sichtweisen gültig, aber sie wirken wie Teile einer größeren Geschichte, die nicht ganz klar ist. Wenn ein Entwickler weiß, dass ein Teil seines Codes nur für den internen Gebrauch bestimmt ist, warum kann er dann ein Paket nicht so einfach verstecken wie eine Klasse oder ein Feld? Wenn Code nur dann kompiliert und ausgeführt werden kann, wenn seine Abhängigkeiten vorhanden sind, warum fließen diese Abhängigkeiten dann nicht reibungslos von der Kompilierung über die Paketierung bis zur Installation und Ausführung? Wenn Werkzeuge nur dann funktionieren, wenn sie unverfälschte, selbstbeschreibende Artefakte enthalten, wie kann man dann ältere Bibliotheken wiederverwenden, die einfach nur JAR-Dateien sind?

Java 9 bietet eine kohärente Geschichte für Modularität, indem es Module als erstklassiges Merkmal der Java-Plattform einführt. Ein Modul ist eine Gruppe von Paketen, die für die Wiederverwendung konzipiert sind. Dieses einfache Konzept hat einen überraschend starken Einfluss darauf, wie Code entwickelt, eingesetzt und ausgeführt wird. Die altbewährten Mechanismen zur Förderung und Kontrolle der Wiederverwendung in Java - Schnittstellen, Zugriffskontrolle, JAR-Dateien, Klassenlader, dynamisches Linking - funktionieren alle besser, wenn die Pakete in Modulen zusammengefasst sind.

Erstens verdeutlichen Module die Struktur eines Programms auf eine Weise, wie es andere Mechanismen nicht können. Viele Entwickler werden überrascht sein, dass ihr Code nicht so gut strukturiert ist, wie sie dachten. Bei einer Codebasis, die über mehrere JAR-Dateien verteilt ist, besteht zum Beispiel eine gute Chance, dass es Zyklen zwischen Klassen in verschiedenen JAR-Dateien gibt, aber Zyklen zwischen Klassen in verschiedenen Modulen sind untersagt. Einer der Gründe, in die Modularisierung einer Codebasis zu investieren, ist die Gewissheit, dass es nach der Fertigstellung keinen Rückfall in den Schlamassel gibt, den zyklische Abhängigkeiten ermöglichen. Die Entwicklung mit Modulen führt auch zur Programmierung mit Diensten, die die Kopplung reduzieren und die Abstraktion noch weiter erhöhen.

Zweitens vermitteln Module ein Gefühl der Verantwortung für den Code, wie es andere Mechanismen nicht können. Ein Entwickler, der Pakete aus einem Modul exportiert, verpflichtet sich zu einer stabilen API, und sogar der Name des Moduls selbst ist Teil der API. Ein Entwickler, der zu viele Funktionen in einem einzigen Modul bündelt, führt dazu, dass dieses Modul eine große Anzahl von Abhängigkeiten mit sich bringt, die für jede einzelne Aufgabe irrelevant sind; jeder, der das Modul wiederverwendet, wird seine ausufernde Natur erkennen, selbst wenn seine Interna verborgen sind. Die Entwicklung mit Modulen ermutigt jeden Entwickler dazu, über die Stabilität und den Zusammenhalt seines Codes nachzudenken.

Die meisten Menschen kennen den Tischtuchtrick, bei dem das Tuch vom Tisch gefegt wird, ohne die Teller und Tassen umzustoßen. Für diejenigen von uns, die an Java 9 gearbeitet haben, fühlte sich die Entwicklung eines Modulsystems, das sich unter die Millionen von Klassen, die seit den 1990er Jahren entwickelt wurden, in die Java Virtual Machine schieben konnte, eher wie die umgekehrte Ausführung des Tricks an. Es stellte sich heraus, dass die Modularisierung des JDK dazu führte, dass der Trick fehlschlug, weil einige bekannte Bibliotheken ihre Stärke daraus zogen, dass sie versuchten, genau die Kapselung zu ignorieren, die das Modulsystem auf die Module des JDK anwendet. Auf diese Spannung im Design von Java 9 gab es keine einfachen akademischen Antworten. Letztendlich führte ein starker Feedback-Zyklus aus der Community dazu, dass das Modulsystem den Entwicklern eine Reihe von Hebeln und Reglern bietet, so dass modularisierter Plattformcode wirklich stark gekapselt sein kann, während modularisierter Anwendungscode "stark genug" gekapselt sein kann. Wir glauben, dass die mutigen Entscheidungen, die bei der Modularisierung des JDK getroffen wurden, mit der Zeit den gesamten Code zuverlässiger machen werden.

Ein Modulsystem funktioniert am besten, wenn es für alle funktioniert. Je mehr Entwickler heute Module erstellen, desto mehr Entwickler werden morgen Module erstellen. Aber was ist mit den Entwicklern, die ihre Module noch nicht erstellt haben? Es ist keine Übertreibung zu sagen, dass Java 9 sich genauso um den Code kümmert, der nicht in Modulen ist, wie um den Code, der in Modulen ist. Der einzige Entwickler, der eine Codebasis modularisieren sollte, ist ihr Autor. Solange das nicht geschieht, muss das Modulsystem eine Möglichkeit bieten, dass der Code in Modulen den Code erreicht, der nicht in Modulen enthalten ist. Dies führte zur Entwicklung von automatischen Modulen, die in diesem Buch so gut erklärt werden.

Sander und Paul sind erfahrene Java-Experten und vertrauenswürdige Führer durch das Java 9-Ökosystem. Sie waren an vorderster Front an der Entwicklung von Java 9 beteiligt und standen an der Spitze der Bemühungen, beliebte Open-Source-Bibliotheken zu migrieren. Java 9 Modularity ist das Handbuch für alle, die sich für die Grundprinzipien und bewährten Methoden der Modularität in Java interessieren: Anwendungsentwickler, die wartbare Komponenten erstellen wollen, Bibliotheksentwickler, die Ratschläge zur Migration und Reflexion suchen, und Framework-Entwickler, die die fortschrittlichen Funktionen des Modulsystems nutzen wollen. Ich hoffe, dieses Buch hilft dir dabei, Java-Programme zu erstellen, die durch ihre Struktur den Test der Zeit bestehen können.

Alex Buckley
Java Platform Group, Oracle
Santa Clara, Juli 2017