Suche

Java 8: Oracle stellt JDK-Modularisierung in Project Jigsaw vor

Hartmut Schlosser

Projekt Jigsaw ist bekanntlich der Codename für die Anstrengungen, ein Modulsystem für die Java-SE-Plattform zu entwickeln. In Java kann man zwar heute schon eine Gruppe von Ressourcen beispielsweise in einer jar-Datei zusammenfassen und damit so etwas wie ein Modul bereitstellen. Bis dato ist es indes nicht möglich zu beschreiben, was genau ein Modul anderen Modulen zur Verfügung stellt, was es seinerseits wieder braucht und in welchen Versionen es Ressourcen beziehen soll.

Das Modulsystem aus Project Jigsaw soll Abhilfe schaffen. Es soll einerseits auf das JDK selbst angewendet werden und kann andererseits auch für eigene Java-Anwendungen genutzt werden. Als Einschlagsziel für die Fertigstellung von Jigsaw hat Oracle das Datum Mitte 2013 im Rahmen der Veröffentlichung von JDK 8 ausgegeben.

Der verantwortliche Oracle-Architekt Mark Reinhold hat nun den aktuellen Stand von Jigsaw in einem Draft-1-Papier vorgestellt. Dort werden als wichtigste Design-Prinzipien die einfache Zugänglichkeit und die Skalierbarkeit genannt. Werfen wir einen kurzen Blick auf den im Papier beschriebenen Stand von Project Jigsaw.

Project Jigsaw: Basics

Grundsätzlich soll die Java-Sprache selbst um die neue Komponente „Module“ erweitert werden. Private Klassen innerhalb von Modulen sollen genauso behandelt werden wie private Felder innerhalb von Klassen, d.h. Modul-Grenzen bestimmen die Sichtbarkeit und den Zugriff auf Klassen und Interfaces. Das Modulsystem soll für gängige Szenarien optimiert sein, beispielsweise werden dynamische Modulaufrufe zur Laufzeit und die simultane Nutzung verschiedener Versionen eines Moduls nur bedingt unterstützt. Optimiert wird für eine sogenannte „statische, Single-Version-Modul-Resolution“, über Umwege soll aber auch der Spezialfall einer dynamischen, „Multi-Version-Resolution“ möglich sein.

Module

Das neue Sprachelement Module besteht aus einer Sammlung von Java-Typen wie Klassen oder Interfaces. Module erhalten einen Namen, eine Versionsnummer und eine formale Beschreibung der Abhängigkeiten zu anderen Modulen. Neben Java-Typen können Module auch Ressource-Dateien, Configuration Files, native Bibliotheken und Anweisungen enthalten. Zudem ist es möglich, Module kryptographisch zu signieren, um Zugriffrechte verwalten zu können.

Als wichtigster Typ von Beziehungen zwischen Modulen wird die Beziehung „dependence“ eingeführt, wo ein Modul die Namen und gegebenenfalls die zugelassenen Versionen der Module spezifiziert, von denen es abhängt.

Die einfachste Modul-Deklaration nimmt die folgende Form an:

module foo { }

Versionsnummern werden nach einem einleitenden @ hinter dem Namen platziert:

module foo @ 1.0 { }

Der Modul-Lebenszyklus

Im Lebenszyklus eines Moduls gibt drei Phasen:

  1. Zur Compile-Zeit werden die Abhängigkeiten eines Moduls aufgelöst. Als Ergebnis erhält man ein Kompilat, das fertig für die Veröffentlichung paketiert ist.
  2. Zur Install-Zeit werden Module in eine Module-Bibliothek eingefügt, die beispielsweise aus einer Sammlung bereits vorher installierter Module besteht. Wenn ein Modul aufrufbar (invokable) ist, etwa bei Vorhandensein eines Entry Points, werden die Abhängigkeiten aufgelöst und die Ergebnisse in einer persistenten Configuration-Komponente abgelegt.
  3. Zur Laufzeit werden aufrufbare Module in eine Java Virtual Machine geladen und gemäß der Install-Time-Configuration mit den anderen Modulen verbunden, von denen es abhängt.

Beim Kompilieren eines Moduls schreibt der Java-Compiler Klassendateien in ein spezielles Klassen-Directory, „module-path layout“ genannt. Für jedes Modul gibt es dort ein Top-Level-Directory, der Inhalt jedes Modul-Directorys ist strukturiert wie ein normales Klassen-Directory (Baum von Java-Package-Namen).

Der Java-Launcher soll modulare Anwendungen dann direkt vom module-path-Directory aus starten können. Die Auflösung der Abhängigkeiten wird in diesem Fall vor dem Aufruf der Entry Points einer Anwendung durchgeführt, während die resultierende Konfiguration dann nicht für zukünftige Einsätze gespeichert wird.

Gemäß den anfangs genannten Design-Prinzipien soll es nicht möglich sein, Abhängigkeiten oder Module dynamisch hinzuzufügen, nachdem eine Anwendung gestartet wurde. Solche dynamischen Effekte, wie sie von Application Servern oder IDEs benötigt werden, sollen indes „in begrenztem Maße“ über das Modul-System API möglich sein. Module können in eine temporäre Modul-Bibliothek installiert und von dort aus gestartet werden.

To Do

Das Draft-1-Papier enthält zahlreiche weitere Spezifikationen, etwa für Exports, Versions-Limitierungen, Zugriffsrechte und Services. Wer auf dem Laufenden über die Zukunft von Java bleiben möchte, sollte auf alle Fälle einen Blick riskieren.

Am Ende des Drafts steht übrigens auch, welche Arbeit in den nächsten Wochen und Monaten noch ansteht:

Still to come

  • Compilation
  • Packaging
  • Libraries
  • Repositories
  • Module-system API
  • JDK modularization
  • Geschrieben von
    Hartmut Schlosser
    Kommentare

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht.