Suche
Quo vadis Jigsaw?

Java 9 Update: So geht es weiter mit Projekt Jigsaw

Hartmut Schlosser

(c) Shutterstock / hobbit

 

Gut zwei Wochen ist es her, dass das Exekutiv-Komitee des JCP das Java-9-Modulsystem Jigsaw abgelehnt hat. Seither laufen die Nachbesserungsarbeiten auf Hochtouren. Wo wir momentan stehen, zeigen die veröffentlichten Protokolle der Meetings der Jigsaw-Expertengruppe. Die gute Nachricht: Es scheint sich tatsächlich ein breiterer Konsens abzuzeichnen…

Die Protokolle zweier Experten-Gruppen Meetings stehen zur Einsicht bereit. Das erste fand am 18. Mai, das zweite am 22. Mai statt. Ziel der Videokonferenzen ist es, verbleibende Problemstellen in der Jigsaw-Spezifikation zu diskutieren und einen Konsens darüber zu finden, wie mit den Problemen weiter verfahren werden sollte.

Idealerweise soll am Ende der Meeting-Runden eine Liste stehen, auf der jeder diskutierte Problempunkt einer der folgenden drei Lösungen zugeführt wurde:

  • NOW — Das Problem soll noch für Java 9 gelöst werden.
  • LATER — Das Problem soll in einer späteren Java-Version gelöst werden.
  • NEVER — Das Problem soll gänzlich fallengelassen werden.

Zu Beginn des ersten JCP-Meetings standen indes zwei Ankündigungen, die zwar nicht direkt mit dem Java-9-Modulsystem zu tun haben, deren Tragweite aber umso höher ist.

Java 9: Zugriff auf interne APIs

Bereits kurz nach dem negativen JCP-Voting hatte Oracle eine wichtige Änderung vorgeschlagen. Es soll in Java 9 nun doch per Default möglich sein, über Reflection Zugriff vom Quellcode aus auf den Klassenpfad zu erhalten. Oracles Mark Reinhold begründet diesen Rückzieher der eigentlich vorgesehenen strikten Kapselung mit dem Feedback aus der Community: Die Community-Tests der JDK 9 Early Access Builds hätten ergeben, dass ein Verbot dieser Art des Zugriffs von einem Java-Release auf das andere als zu aggressiv empfunden werde.

Standardmäßig soll der reflektive Zugriff im JDK 9 also doch möglich sein, wenngleich beim ersten Mal eine Warnmeldung ausgegeben werden soll. In einem zukünftigen Release sollen solche Zugriffe aber dann ausgeschlossen werden.

Java-Releases sollen häufiger werden

Die zweite Ankündigung ist eigentlich eine Bestätigung. Es geht um die in vorangegangenen Meetings bereits diskutierten Pläne für einen agileren Java-Release-Zyklus: Zukünftig soll die Frequenz der Java-Releases erhöht werden. Die bisherige Vorgehensweise, alle zwei bis drei Jahre eine neue Java-Version mit großen neuen Features zu veröffentlichen, sei nicht mehr zeitgemäß, sagt Mark Reinhold. Java-Releases sollen deshalb häufiger kommen, die Rede ist von einem jährlichen oder 6-monatigen Release-Zyklus.

Vermieden werden soll dadurch vor allem das Verschieben eines Java-Releases nur deshalb, weil das „große neue Feature“ nicht rechtzeitig fertig wurde – wie das ja auch in Java 9 mit seinem Projekt Jigsaw der Fall war.

Java-Releases sollen also eher Termin-gebunden denn Feature-getrieben organisiert werden. Die Vorteile: Kleinere Neuerungen stehen schnell zur Verfügung. Wenn ein „Big Feature“ nicht rechtzeitig fertig wird, wird es auf das nächste Java-Release verschoben. Der Innovationszug wird dadurch aber nicht aufgehalten.

Quo vadis Jigsaw?

Nach diesen beiden Ankündigungen nun zur Jigsaw-Spezifikation, dem eigentlichen Grund für die Meeting-Runde. Zu Jigsaw diskutierte die Experten-Gruppe noch offene, als kontrovers geltende technische Aspekte. Wir fassen jeweils die Ergebnisse der Diskussionen zusammen:

#AutomaticModuleNames & #ModuleNameInManifest

Diese beiden Features waren für den Widerstand aus dem Apache-Maven-Lager verantwortlich. Oracle hat darauf reagiert und ein neues Proposal vorgelegt. Der Algorithmus, der die Namen für automatische Module erstellt, berücksichtigt jetzt auch den Maven Guppen-Identifizierer, sofern ein solcher im pom.properties File vorliegt.

RESOLUTION: NOW, as previously decided here and here. Additional guidance should be provided in an addendum to the specification or in a separate document.

#ModuleIdentifiers

Hier geht es darum, dass viele von Jigsaw eigentlich erwartet hätten, mit dem Problem der multiplen Versionen umgehen zu können. Im ersten JCP-Meeting stellte Mark Reinhold zwar heraus, dass dieses Problem absichtlich nicht in Java 9 behandelt werden sollte. Doch sei es eventuell klug, die Jigsaw-Spezifikation auf die Lösung des Problems in einem späteren Release vorzubereiten.

Sein erster Vorschlag lautete deshalb, Module nicht nur durch einen einfachen String-Namen zu identifizieren. Stattdessen könnte eine neue Klasse ModuleId eingeführt werden, die in späteren Java-Versionen zusätzliche Informationen tragen könnte.

Hier konnte allerdings noch kein Konsens erzielt werden – alternative Vorschläge wie die Einführung eines kodierten Strings wurden im JCP-Meeting diskutiert. Im zweiten JCP Meeting kam zudem die Möglichkeit ins Spiel, multiple Versionen von Modulen desselben Namens durch Overloading existierender String API-Methoden zu behandeln.

Im Endeffekt wurde entschieden, dass dieses Problem auf ein späteres Java-Release verschoben werden soll, da noch kein Konsens über eine technische Lösung gefunden werden konnte.

RESOLUTION: LATER, since the current specification has the necessary flexibility to extend the module system to handle multiple versions in a later release.

#VersionsInModuleNames

Zu diesem Punkt gibt es ein neues Vorgehen: Der Algorithmus für automatische Modulbenennung erlaubt nun auch Zahlen am Ende von Modulnamen.

RESOLUTION: NOW, as previously decided.

#MoveModuleAndLayerClasses

Hier wurde beschlossen, die Klassen „Module“ und „Layer“ sowie eine darauf bezogene Exception-Klassen vom Package `java.lang.reflect` nach `java.lang` zu verschieben.

RESOLUTION: NOW, as previously decided.

#StandardModuleAttributes

Hier werden vorerst die in der aktuellen Jigsaw-Spezifikation vorgesehenen Attribute standardisiert. Zukünftige Releases könnten aber weitere Attribute definieren.

RESOLUTION: NOW, as proposed: Standardize the attributes presently in the specification. A future specification may standardize additional attributes.

#CompilationWithConcealedPackages

Hier gibt es einen aktualisierten Vorschlag, der momentan von den Eclipse-Vertretern evaluiert wird.

RESOLUTION: PENDING: Eclipse to review the proposed specification, which has since been published.

#CyclicDependences

Für diesen Problem wird eine spätere Lösung angestrebt.

Resolution Cyclic dependences will not be supported at this time. They could be supported in a later revision, if necessary, after a thorough analysis of the impact of this change on both the specification and the implementation. [EG discussion; Mark Reinhold; later discussion: Robert Scholte, Mark Reinhold; earlier discussion]

#ResolutionAtCompileTime

Hier will Oracle bald eine aktualisierte Spezifikation vorlegen.

RESOLUTION: PENDING: Oracle to provide updated specification for review.

#VersionSyntax

Bei diesem Punkt soll trotz einiger Gegenargumente das ursprüngliche API beibehalten werden.

RESOLUTION: NOW, retaining the existing API.

#AvoidConcealedPackageConflicts

Die Lösung des Problems wird auf ein späteres Release verschoben. Darüber drückten einige Experten ihre Enttäuschung aus. Doch ist man noch weit von einer allgemein akzeptierten technische Lösung entfernt. Konsens herrschte nur darüber, dass das Jigsaw-Modulsystem mit diesem Problem umgehen können sollte.

RESOLUTION: LATER (regretfully), as previously decided.

Und jetzt?

Die Diskussionen gehen weiter – und wie man den Protokollen entnehmen darf, durchaus in einem konstruktiven Ton. Die Zeit ist allerdings knapp. Bereits am 7. Juni muss die Gruppe eine überarbeitete Spezifikation des gesamten Modulsystems (JSR 376) vorlegen. Es folgt dann eine erneute Abstimmung durch das JCP Exekutiv-Komitee. Sollte der Entwurf dann angenommen werden – womit zu rechnen ist -, bleibt den Experten noch Zeit bis zur endgültigen Ausarbeitung. Denn nach wie vor ist das Java 9 Release für den 27. Juli 2017 angesetzt.

UPDATE:

Mittlerweile wurde der Release-Termin von Java 9 auf den 21. September 2017 verschoben.

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

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