Neuheiten Java 9 (Teil I) Java 9 - Was lange währt

Wer kann sich noch erinnern? Im März 2014 kam das letzte Java Major Release Java 8 und es gab sehr viel Neues, wobei sich vor allem Lambda-Ausdrücke und die mächtige Stream- API hervortaten. Am 21. September 2017 kam nun endlich das mit Spannung erwartete Java 9 heraus, um mit der Hauptneuerung „Modularisierung" aufzuwarten. 

Was bringt Java 9, warum hat es so lange gedauert und wie können wir am besten vom neuen Release profitieren? Das wollen wir hier und in weiteren Artikeln zum Thema machen. Zunächst fokussieren wir uns auf das folgenreichste neue Feature: Die Modularisierung (läuft bei Oracle unter dem Codenamen „Jigsaw"). Sie geht verschiedene Problematiken im Java-Umfeld an, die sich grob in die Kategorien Sicherheitslücken, JAR-Hell und Spaghetti-Projekte einsortieren lassen.

Modularisierung –
Gab es das nicht schon vorher?

Modularisierung in Java gab es in gewisser Weise schon immer, aber diese beschränkt sich vorwiegend auf Quellcode- Ebene. Jeder kennt die Einteilung in Klassen, die – grob gesprochen – aus einem öffentlich zugänglichen Teilbereich (public) und einen verborgenen, privaten (private) bestehen. Klassen und Interfaces sind ihrerseits wieder in Packages angeordnet, die ebenfalls bezogen auf Sichtbarkeit steuerbar sind (package-visibility). Das ist soweit schön und gut, in der Praxis fehlen aber noch ganz wichtige Zutaten. Wir kommen später noch genauer auf public und die neuen, damit einhergehenden Einschränkungen zu sprechen, die durch Jigsaw Einzug in das JavaÖkosystem halten.

Leider müssen wir nämlich schmerzlich akzeptieren, dass diese Aufteilungs- und Strukturierungsmöglichkeiten mit dem build-Vorgang schlagartig verloren gehen, denn typischerweise gelangt compilierter Bytecode in Archivdateien (*.jar, *.war). Deren Namensgebung ist weitgehend beliebig. Diese Dateien werden deployed oder allgemeiner gesprochen ausgeliefert und sie repräsentieren häufig die eigentliche Applikation. Zur Laufzeit werden nun die Klassen und Interfaces aus den Archivdateien vom Classloader geladen und die Gesamtheit aller geladenen Java Konstrukte machen die lauffähige Anwendung aus.

Die Problematik resultiert aus mangelnden Vorgaben und Regelungsmöglichkeiten zum Aufbau und zur Struktur von solchen Archivdateien. In einer JAR-Datei können prinzipiell beliebig viele und beliebig abhängige Java-Klassen untergebracht sein. Sobald sie geladen sind, geht die Information, aus welcher JAR-Datei sie stammen, verloren.

Die JAR-Hell- und Security-Einfallstore

Worin besteht denn nun genau das Problem und was haben JAR-Dateien damit zu tun? Es kommt zu einem großen Bruch beim Übergang von Quellcode zum Binärformat, weil es die Eigenschaft der Kapselung so nicht bei Java-Artefakten gibt (wie man JAR-Dateien auch nennt). Daraus folgt zum Beispiel, dass sich sensibler Code nur schlecht schützen lässt sobald er im Binärformat vorliegt. Und das Binärformat kommt praktisch überall vor, selbst das JDK (Java Devolpment Kit) ist im Wesentlichen nichts anderes als eine Ansammlung von Archivdateien (z.B. $JRE_HOME/lib/rt.jar, welches die Java-Kernklassen beinhaltet).

Diese mangelnde Schutzmöglichkeit musste selbst Oracle schmerzlich erfahren, als mit dem Erwerb von Java und der Auslieferung von Java 7 eine Vielzahl von Sicherheitslücken offenkundig wurden und es zahlreicher Patches bedarf, diese zu schließen. Denn sicherheits kritische Codestellen waren in den JDK-Archiven mit relativ einfachen Mitteln (Stichwort Reflection) lesbar, untersuchbar und schlimmstenfalls manipulierbar. Schadsoftware hatte dadurch relativ leichtes Spiel und leichten Zugang zu Java-Kernklassen. Das lag u.a. an der einfachen Möglichkeit, die $JRE_HOME/lib/rt.jar und andere JAR-Dateien mit einem prinzipiellen Zugriffsschutz auszustatten, was dann auch von der kriminellen Hackerszene weidlich ausgenutzt wurde.

Module weisen den Weg ins Glück

• Einen Namen oder eine eindeutige ID 
• Abhängigkeiten: Was braucht mein Modul, wovon bin ich abhängig? 
• Nutzbare API: Was kann ich anbieten, wie sieht die öffentliche Schnittstelle aus?

Wichtige Konzepte des JPMS

module myapp.mod1 {
   requires mod2;
   exports de.ordix.pkg1;
   exports de.ordix.pkg2;
}
module myapp.mod1 {
   exports de.ordix.pkgA;
} 

Abb. 2: Die Inhalte von 2 Moduldeskriptoren, abgelegt in den jeweiligen Verzeichnissen in den Deskriptor Dateien modul-info.java

src/myapp.mod1/
    module-info.java
    de.ordix.pkg1/
      ClassA.java
      ClassB.java
...
    de.ordix.pkg2/
      ClassC.java 

Die Wirkungsweise von JPMS

Um die Vorteile von JPMS erkennen zu können, müssen wir einen genauen Blick auf dessen Bedeutung und Semantik werfen. Das Schlüsselwort public hat früher signalisiert: Die Klasse oder das Interface ist global im Anwendungskontext nutzbar, sofern das zugehörige Package per import herangezogen wurde. Im neuen Java 9 heißt public: Eine so spezifizierte Klasse ist nur innerhalb des Moduls von überall ansprechbar. Von einem anderen Modul nur genau dann, wenn das zugehörige Package mit der Klasse per exports freigegeben wird und das andere Modul es per requires anfordert. Das ist revolutionär, denn es bringt – endlich muss man sagen – echten Zugriffsschutz. Eine public-Klasse, die nicht exportiert wird, kann von außerhalb des Moduls nicht angesprochen werden, auch nicht über Reflection-Mechanismen!

Fazit

Glossar

Links/Quellen

[1] Java-Seminare bei der ORDIX AG https://seminare.ordix.de

[2] Download des Java 9 JDK http://openjdk.java.net/projects/jdk9/

[3] Modulare Java-Zukunft https://www.heise.de/developer/artikel/Modulare-Java-Zukunft-Das-Java- Platform-Module-System-erklaert-3700766.html