"Die Modularität ist so etwas wie ein Sicherheitsgurt"

Auf der Zielgeraden zur Veröffentlichung von Java 9 hat heise Developer Brian Goetz zu den Neuerungen befragt. Er äußert sich zum Modulsystem, anderen JVM-Sprachen, seinem Lieblings-Feature in Java SE 9 und seinen Wünschen für die Zukunft.

In Pocket speichern vorlesen Druckansicht 3 Kommentare lesen
"Die Modularität ist so etwas wie ein Sicherheitsgurt"
Lesezeit: 7 Min.
Von
  • Rainald Menge-Sonnentag
Inhaltsverzeichnis

heise Developer: Herr Goetz, Java 8 brachte den funktionalen Programmierstil, Java 9 endlich ein Modulsystem. Was hat mehr Einfluss auf die tägliche Arbeit von Java-Entwicklern?

Brian Goetz: Jede dieser großen Plattformverbesserungen zielt darauf ab, die Leiden der Entwickler zu lindern. Wir haben Lambda-Funktionen nicht eingeführt, weil der funktionale Programmierstil populär ist. Sie wurden entworfen, weil sie den besten Weg darstellen, Java-APIs ausdrucksvoller, performanter und sicherer zu machen. Mit ihnen sorgen wir für ein besseres Java-Ökosystem.

Die primäre Motivation für das Modulsystem war die Erkenntnis, dass Java bei beispiellos skalierbaren und komplexen Systemen eingesetzt wird. Java besitzt schon seit jeher Features zum Strukturieren großer Codebasen: Pakete für Namespaces, Zugangskontrollen für die Datenkapselung, Classloader zur Isolierung, Schnittstellen zur Abstraktion und so weiter. Aber letztlich verwenden die meisten Menschen eine Mischung aus Skripten und Tools, um die Codebasis in ein lauffähiges System zu verwandeln. Etwas im Kern von Java schien also zu fehlen.

Mehr Infos

Brian Goetz

ist Java Language Architect bei Oracle und war für die Spezifikation des JSR 335 (Lambda Expressions für Java) zuständig. Er ist Autor des Bestsellers "Java Concurrency in Practice" sowie von über 75 Artikeln zu Java-Entwicklung. Seine Begeisterung zur Programmierung geht bis in die Zeiten zurück, als Jimmy Carter Präsident wurde.

Die Einführung eines Modulsystems bedeutet, dass sich jede Codebasis in Form von Modulen strukturieren lässt, die die Features strukturiert zusammenfassen und sie alle besser machen können. Beispielsweise wird durch die Module ersichtlich, ob Pakete für den "internen" Gebrauch bestimmt sind oder als APIs verwendet werden sollen. Das reduziert Bugs, erleichtert die Wartung und fördert die Wiederverwendung. Letztlich kommen die Module besser den Intentionen der Entwickler nach als Dinge wie Dokumentation, Tests, Skripte und Tools.

Wenn Features wie Lambda-Funktionen als "Jetpack" für Entwickler beschrieben werden, dann ist die Modularität so etwas wie ein "Sicherheitsgurt". Zwar bekommen Raketenrucksäcke mehr Aufsehen als Sicherheitsgurte, tatsächlich brauchen wir jedoch Leistungsfähigkeit und Sicherheit, um korrekte, zuverlässige und robuste Programme zu bauen.

heise Developer: Warum hat es so lange gedauert, ein Modulsystem zu implementieren? Erste formale Ideen stammen ja bereits von 2005.

Goetz: Die gleiche Frage ließe sich auch zu Generics oder Lambdas stellen – beide waren fast zehn Jahre im Gespräch, bevor sie in Java gelandet sind. Auf einer der letzten JavaOne-Konferenzen sprach James Gosling darüber, dass er und seine Entwickler sich vom ersten Tag an der Notwendigkeit der Generics bewusst gewesen wären. Sie wurden aber erst mal nicht Bestandteil der Sprache, weil Gosling und seine Mitstreiter keine zu Java passende Umsetzung gefunden hatten. Wenn Generics schon in Java 1.0 gelandet wären, hätten wir wahrscheinlich so etwas wie C++-Templates bekommen – und ich denke, wir sind uns alle einig, dass das kein guter Weg gewesen wäre. Java hat eine lange Tradition bei der Suche nach einem effektiven 80/20-Prinzip, nach dem man den größten Vorteil für einen Bruchteil der Komplexität bekommt – und das geschieht in der Regel über langes und intensives Nachdenken darüber, was wesentlich ist und was nicht.

Es sei daran erinnert, dass "Java modular zu machen" nicht einfach nur bedeutet, ein Modulsystem zu entwerfen – das ist wohl der "einfache" Teil. Es dauerte allein schon mehrere Jahre, die JDK-Codebasis zu modularisieren. Verwendet man das Module-System für eine Codebase, die so umfangreich ist wie das JDK, so erhält man im Gegenzug ein weiter verbessertes Design vom Modulsystem. Aber auch das ist nicht wirklich genug, um Entwicklern Modularität mit Java zu ermöglichen. Wie bei den Generics war sicherzustellen, dass es einen sauberen Migrationspfad gibt, über den sich Codebasen allmählich migrieren lassen, da es keine Möglichkeit gibt, dass sofort und über Nacht eine bestehende Applikation modularisiert wird.

Bei Beobachtung der Entwicklung des Jigsaw-Designs in den letzten Jahren bin ich froh, dass wir so lange gewartet haben – das Modulsystem, das wir im JDK 9 bekommen, ist viel einfacher und konzeptuell schlüssiger als die früheren Iterationen des Designs oder als andere Modulsysteme, die für Java vorgeschlagen wurden – und der jetzige Stand ist viel besser dafür vorbereitet, existierende Anwendungen zu unterstützen.

Mehr Infos

Sonderheft "Java 2017"

Mehr Artikel zu Java 9, Java EE 8 und aktuellen Entwicklungen im Java-Umfeld sind im Sonderheft iX Developer Sommer 2017 zu finden, das unter anderem im heise Shop erhältlich ist.

heise Developer: Mal JPMS ausgeklammert, was ist denn das wichtigste Feature von Java 9 für Sie?

Goetz: JShell! Wer noch keine REPL (Read-Eval-Print Loop) aus anderen Sprachen kennt, kann sich wirklich darauf freuen. JShell ist eine interaktive Java-Shell, mit der Entwickler Ausdrücke und Deklarationen direkt eingeben und sie sofort und interaktiv auswerten können. Sie eignet sich wunderbar für das Erkunden von APIs, zum Ausprobieren und für prototypische Ideen. Aufgrund des interaktiven Charakters können Entwickler viel schneller ausliefern, und wenn mal was schiefgeht, können sie sofort eine andere Möglichkeit ausprobieren. Ich hoffe, dass die Shell ein Teil des täglichen Arbeitsprozesses jedes Java-Entwicklers wird.