JavaOne 2015: Rundumschlag zum JDK 9
Haben wir nichts anzukündigen, wärmen wir einfach alte Nachrichten auf. So könnte Oracles bisheriges Motto auf der JavaOne 2015 sein. Zumindest stößt das nächstes Jahr erscheinende Java 9 auf großes Interesse.
- Arno Puder
Mit fünf Vorträgen stimmte Oracle auf der JavaOne 2015 die Java-Gemeinde auf das JDK 9 ein, das laut derzeitigen Plänen im September 2016 erschienen soll. Jetzt, da die Umstellung absehbar ist, ist das Interesse unter Entwicklern groß. Das ist insofern verständlich, weil Modularisierung als wichtigste Neuerung nicht immer Rückwärtskompatibilität garantiert und gegebenenfalls Anpassungen der eigenen Anwendung notwendig sind.
Alan Bateman, Consulting Member of Staff bei Oracle, läutete die Vortragsreihe mit einem allgemeinen Überblick der im JDK 9 anstehenden Neuerungen ein. Es wurde insbesondere Wert auf Flexibilität und Skalierbarkeit gelegt, um die Wartbarkeit und Sicherheit zu verbessern. Zu den trivialeren Änderungen im JDK 9 gehören, dass ein einfacher Underscore (“_”) nun kein legaler Java-Identifier mehr ist und dass "java -version" einen wohldefinierten Versionsnamen liefert. Gerade bei Letzterem war es in der Vergangenheit nicht immer einfach, aktuelle von veralteten Java-Versionen zu unterscheiden.
Modularisierung wider vager Konventionen
Die größte Änderung betrifft das neue Modul-Konzept, das auf dem 2008 gestarteten Jigsaw-Projekt basiert. Über ein neues Schlüsselwort "module" lassen sich Module und ihre öffentlichen APIs definieren. Als eine der größten Herausforderungen stellt sich dabei die Modularisierung des JDK selbst heraus. Seit Java 1.0 gibt es lediglich Konventionen, was zur offiziellen Java API gehört und was nicht.
Die offizielle API ist in der Regel unter den Packages java.*, javax.* und com.sun.* zu finden. Obwohl sun.* inoffizielle API beherbergt, werden einige dieser Klassen gerne von Java-Entwicklern benutzt. Ein Beispiel ist hier sun.misc.BASE64Encoder. Mit der Modularisierung im JDK 9 wird das nun nicht mehr möglich sein und in einer IllegalAccessException resultieren.
Oracle bietet mit "jdeps" (Java Class Dependency Analyzer) ein Werkzeug an, mit dem Entwickler ihre eigenen Anwendungen nach der Nutzung inoffizieller API durchsuchen können. In vielen Fällen bietet jdeps Vorschläge an, welche offiziellen Klassen sich stattdessen benutzen lassen. Viele Projekte müssen noch umgestellt werden, beispielsweise Hadoop oder Gradle, die oftmals auf interne API zurückgreifen. Sollte es dennoch aus zeitlichen Gründen nicht möglich sein, kann mit der Kommandozeilenoption -XaddExports eine Ausnahme definiert werden.
Im Zuge der Aufräumarbeiten wird auch die Verzeichnisstruktur der JRE (Java Runtime Environment) und der JDK Binaries angeglichen. Unter anderem sollten sich Anwendungen nicht mehr auf die Existenz von rt.jar und tools.jar verlassen. Gleichwohl verabschiedet man sich im JDK 9 von den "endorsed directories" sowie dem -Xbootclasspath-Parameter.
Modularisierung en detail
In einem weiteren Vortrag erläuterte Alex Buckley von Oracles Java Platform Group die internen Details des neuen Modulsystems. Letztlich garantieren Module eine starke Kapselung interner Details. Java bietet über sogenannte Classloader bereits seit Beginn einen Mechanismus der Kapselung.
Das Komponenten-Framework OSGi nutzt beispielsweise verschiedene Classloader, um seine Komponenten (Bundles) zu isolieren. Allerdings ist es hier möglich, über das Core Reflection Framework die Kapselung zu umgehen, indem einfach per Reflection interne Methoden aufgerufen werden. Das in JDK 9 eingeführte Modul-System unterbindet das. Tricks wie setAccessible(true) resultieren in einem Fehler für nicht exportierte Methoden.
Um die Migration zu JDK 9 zu vereinfachen, wird zwischen drei verschiedenen Modulen unterschieden:
- Benannte Module, die von einem Programmierer explizit definiert wurden.
- Unbenannte Module, die als Sammelbecken für den bisherigen Classpath dienen.
- Automatische Module, die zwar einen Namen tragen, deren Modulname aber implizit vom Dateinamen der Jar-Datei hergeleitet wird.
Zugriffsregeln steuern, auf was Module zugreifen können. Beispielsweise kann ein benanntes Modul nicht ein unbenanntes Modul importieren, weil das die Kapselung aushebeln würde. In diesem Fall lässt sich die Bibliothek nur als automatisches Modul importieren. (ane)
