Erneute Verschiebung: Java 9 wird wohl erst im September erscheinen

Die erneute Verschiebung von Java 9 erscheint angesichts dessen sinnvoll, dass kürzlich der derzeitige Stand des Java-Modulsystems nicht die Mehrheit in der zuständigen Expertengruppe des Java Community Process gefunden hatte.

In Pocket speichern vorlesen Druckansicht 27 Kommentare lesen
Erneute Verschiebung: Java 9 wird wohl erst im September erscheinen
Lesezeit: 3 Min.
Von
  • Alexander Neumann

Das nächste Release der Programmiersprache Java wird nun wohl doch nicht am 27. Juli 2017 erscheinen. Es liegt nun ein Vorschlag von Mark Reinhold, dem für die Java-Entwicklung verantwortlichen Oracle-Ingenieur, vor, laut dem Java 9 jetzt am 21. September veröffentlicht werden soll. Die erneute Verschiebung ist der Kontroverse im Zuge des Public Review Ballot für den JSR 376 (Java Specification Request) zu einem Java-Modulsystem geschuldet, die offenbar weitere Anpassungen nötig macht.

So wird befürchtet, dass Jigsaw – so der Codename des Modulsystems – erfolgreich bei der Modularisierung von Java selbst funktioniert habe, aber in "echten" Anwendungsszenarien weitgehend ungeprüft wäre. Viele existierende Java-Anwendungen seien unter Jigsaw nicht möglich oder würden erhebliche Architekturanpassungen erfordern. Die größte Sorge vieler Java-Entwickler bezüglich Java 9 ist, dass ihre Anwendungen aufgrund zahlreicher Änderungen nicht mehr ohne Weiteres laufen. Bedenken bereitet dabei unter anderem, dass der Reflective Access, also Zugriff über Reflexion auf den Klassenpfad, verboten sein sollte. Grund dafür ist, dass die internen Java-APIs von der Außenwelt abgeschirmt sein sollen.

Reinhold hatte jedoch vor knapp zwei Wochen vorgeschlagen, den Zugriff in Java 9 zunächst standardmäßig zu erlauben. Die von ihm als "Big Kill Switch" bezeichnete Option --permit-illegal-access soll damit das Standardverhalten der JDK-Runtime werden. Sie möchte Reinhold gleichzeitig umbenennen, um die Steuerung eines abgestuften Zugriffs in die Hände der Nutzer zu legen. Änderungen beim Kompilieren seien allerdings weiterhin nicht vorgesehen. Die vorgeschlagene Option soll Entwicklern bei einer sanfteren Migration helfen, statt wie nach der bisherigen Planung einen harten Schnitt für den Zugriff zu bringen. Selbst nachdem die letzte Option zum Standard wird, soll die manuelle Erlaubnis über die erste Option weiterhin für mindestens ein weiteres Release möglich sein.

Das, was Reinhold vorschlägt, beseitigt sicherlich nicht alle Bedenken hinsichtlich der Migration, allerdings kann das Zerlegen der Migrationsschritte von einem einzigen großen Schritt hin zu mehreren kleineren dazu führen, dass der JSR 376 in einer zweiten "Public Review Ballot"-Runde die erforderliche Mehrheit der JCP-Expertengruppe (Java Community Process) erhalten wird. Denn an einem Scheitern der Bemühungen zu einem Java-Modulsystem ist den meisten involvierten Parteien nicht gelegen, wo die Modularisierung ein Dauerthema der Java-Entwicklung geworden ist, das schon mehrmals aufgeschoben wurde.

Nach dem Scheitern im Public Review Ballot hat es laut Reinhold mehrere Telefonkonferenzen gegeben, in denen die Bedenken der Expertengruppe diskutiert wurden. Die erwähnten Änderungen zusammen mit zusätzlichen Klarstellungen zu den JSRs 376 und 379 (Java SE 9) sollen die Sorgen der Expert Group beseitigen. Ob das gelungen ist, wird sich letztlich ab 7. Juni zeigen, wenn Oracle offiziell eine Überarbeitung vorlegen muss. Die zweite Abstimmung muss bis zum 26. Juni erfolgt sein.

Siehe dazu auf heise Developer:

(ane)