Suche
Wird Jigsaw die Java-Community fragmentieren?

Kritik an Jigsaw: Experten fordern Verschiebung von Java 9

Hartmut Schlosser

(c) Shutterstock/studiostoks

Ist Java 9 auf einem guten Weg? 100 Tage vor dem geplanten Release haben sich Mitglieder der Jigsaw-Experten-Gruppe kritisch zu dieser Frage geäußert. Das jetzige Design des Java-9-Modulsystems sei inakzeptabel und könne gar zu einer Fragmentierung der Java-Community führen. Was ist dran an der Kritik?

Java 9 und Jigsaw – eine unendliche Geschichte?

Wie lange kennen wir nun schon die Debatten um das Modul-System Jigsaw? Diskussionen um die Art und Weise der Modularisierung der Java-Plattform hat es seit der Lancierung des JSR 277 im Jahr 2005 gegeben. Gegenüber standen sich die meist Sun-nahen Befürworter des JSR 277, welcher später in das von Oracle geführte Projekt „Jigsaw“ überging, und das Lager der OSGi-Entwickler, die mit ihrem im Embedded-Bereich entstandenen Modulsystem eine bereits fertige und seit mehreren Jahren produktiv eingesetzte Technologie mit in die Diskussion einbrachten.

Nun schien Jigsaw nach vielen Verschiebungen endlich für das Java 9 Release am 27. Juli 2017 reif zu sein. Doch wirft ein offener Brief von Red Hat und einigen Mitgliedern der JPMS-Experten-Gruppe erneut die Frage nach der Existenzberechtigung von Jigsaw auf. Der Hauptkritikpunkt lautet, dass das jetzt vorgesehene Jigsaw-Modulsystem viele Use-Cases, die in heutigen Java-Anwendungen üblich seien, verhindere bzw. als Anti-Pattern brandmarke.

Was stimmt nicht mit Jigsaw?

Gezeichnet ist der Blogpost von durchaus prominenten Mitgliedern der Community: Die RedHat’er David Lloyd, Jason Green, Scott Stark, Mark Little und Mark Proctor gehören zu den Autoren; außerdem sind der Apache-Maven-Chairman Robert Scholte, OSGi-Veteran Neil Bartlett von Paremus sowie Brian Fox von Sonatype mit von der Partie.

Wie lauten ihre Argemente?

Das Modulsystem Jigsaw sei eine Erfindung auf dem Reißbrett, die in der Welt der echten Anwendungsentwicklung noch völlig unerprobt sei, schreiben die Kritiker. Dabei laufe das aktuelle Design von Jigsaw darauf hinaus, anstatt neue Möglichkeiten zu eröffnen, eigentlich unnötige Restriktionen einzuführen. Was für die Modularisierung und Kapselung der Java-Plattform selbst sinnvoll sei, werde auf den Bereich der Anwendungsentwicklung übertragen, wo es eine Design-Philosophie erzwinge, die viele andere Philosophien ausschließe.

JDK 9 und die Plattformmodularisierung: So funktioniert Projekt Jigsaw

Damit mache man es vielen Anwendern schwer, ihre existierenden Anwendungen auf Jigsaw zu portieren. Aufgrund der neuen Restriktionen – aber auch wegen vermeintlich unzureichender Interoperabilitätsfunktionen – drohe gar eine Fragmentierung der Java Community in eine „Jigsaw-Welt“ und eine „Nicht-Jigsaw-Welt“ (genannt werden hier Java SE Classloaders, OSGi, Java EE, etc.).

Im Blogpost werden u.a. die folgenden Problem-Punkte beschrieben:

  • Cyclic Dependencies
  • Inadequate Isolation
  • Concealed package conflicts
  • Lack of Mutability
  • Inadequate Compatibility Strategy
  • Unusual API Constructs
  • Module Naming Restrictions

Ziel verfehlt?

Ein weiterer Kritikpunkt bezieht sich auf die ursprünglich im JSR vorgesehenen Ziele des Modulsystems. Anstatt wie geplant leicht zugänglich und skalierbar zu sein, seien Jigsaw-Anwendungen voraussichtlich weniger robust und wartungsintensiver als heutige Java-Anwendungen.

Ein weiteres Jigsaw-Ziel war ursprünglich, die Basis für Java EE 9 zu bilden. Dafür stehen die Karten aber schlecht, meinen die Jigsaw-Kritiker. Bleibe es bei dem jetzigen Jigsaw-Design, müssten Java-EE-Anbieter (wie z.B. Red Hat) die Kompatibilität mit früheren Java-EE-Spezifikationen aufgeben.

Lesen Sie auch: Java 9: neuer, toller, bunter? – Ein Blick auf die Features der neuen Version 

Fazit: Jigsaw könne weder als akzeptable fertige Lösung noch als akzeptable vorläufige Lösung betrachtet werden. Denn die Muster, die mit Jigsaw eingeführt würden, seien in späteren Releases sehr schwer zu verändern:

The patterns introduced within Jigsaw are (in some cases) going to be extremely difficult to fix even in a later release, and will create backwards- and forwards-compatibility problems that will be very difficult to unwind.

Im Ergebnis werde das Java-Ökosystem durch Jigsaw geschwächt, und das zu einem Zeitpunkt, wo sich im Server-Bereich viel bewegt und neue Wettbewerber wie Google Go auftreten.

Was schlagen die Kritiker vor?

Die Kritiker geben die folgende Tabelle aus, die die Möglichkeiten verschiedener Modularisierungslösungen beschreiben:

 

Da nun einige der oben genannten Punkte relativ schnell behoben werden könnten, schlagen die Kritiker einen weiteren Aufschub von Java 9 vor. Anstatt aus Gründen des Zeitdrucks eine Lösung festzuschreiben, die nicht alle Use Cases abdecke, sollte man sich die Zeit nehmen, einfache Probleme wie „layer primitives, circularity, version restrictions“ zu lösen und evtl. auch Hooks einzubauen, die Drittpartei-Quellcode dabei helfen würden, von Jigsaw zu profitieren.

A small delay is worth the cost if the alternative is rushing a solution that doesn’t cover all use cases.

Was ist dran?

Es stellt sich hier Frage, was an diesen Kritikpunkten neu ist. Das Argument, dass eine Modularisierung der Java-Plattform und ein Modul-Standard für die Anwendungsentwicklung zwei verschiedene Paar Schuhe sind, hatte etwa Neil Bartlett schon 2015 angebracht.

Jigsaw ein Projekt zu nennen, das rein auf dem Reißbrett entstanden sei und keine Praxis-Erfahrungen einbeziehe, scheint angesichts der langen Diskussionen in den Expertengruppen (an denen sich auch Red Hat und viele andere beteiligt haben) und der daraufhin immer wieder erfolgten Anpassungen des Modulsystems nicht sonderlich schlüssig.

So kommentiert Mike Hearn, der sich an den Diskussionen auf den Mailing-Listen beteiligt hat, dass man beim Lesen dieser Jigsaw-Kritik nicht die Warte vergessen darf, aus der heraus sie geschrieben wurde:

Although [the document] lists the authors at the top, a casual reader can be forgiven for not knowing that many of them work on what are effectively competitors to Jigsaw like JBoss Modules and OSGi.

Nun belassen es die Kritiker nicht bei diesen Pauschalisierungen, sondern gehen technisch durchaus ins Detail. Dabei kommen echte Problempunkte zur Sprache, etwa:

  • die Design-Entscheidung, alle Module des Module-Paths in einen einzigen Classloader zu zwingen
  • die Design-Entscheidung, Plattform- und Applikationsmodule in den selben Layer zu packen
  • die Restriktionen bei der Modul-Namensgebung
  • die Umbenennung des JSR 250-Moduls von java.annotation in javax.annotations
  • der sogenannte „Kill Switch“
  • etc.

Keine Frage, diese Punkte können kontrovers diskutiert werden. Und genau das ist bereits geschehen: Viele der genannten Punkte wurden ausführlich in den Expertengruppen besprochen, bevor eine endgültige Design-Entscheidung gefällt wurde. Dass nicht alle mit diesen Entscheidungen konform gehen, dürfte in der Natur neuer Projekte liegen.

Wie dem auch sei, wer die Entwicklungen um Jigsaw verfolgt, sollte sich näher mit den Argumenten der Jigsaw-Kritiker befassen. Ob sich Oracle indes drei Monate vor dem geplanten Java-9-Release zu einem erneuten Aufschub bewegen lässt, bleibt abzuwarten.

Mehr zum Thema:

Projekt Jigsaw und Co.: Das erwartet uns in Java 9

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
  1. TestP2017-04-20 08:23:37

    Die Kritik fällt denen aber sehr früh ein. Die meisten Kritiker sind von Redhat und Redhat sitzt ganz oben im JCP. Was haben die die ganze Zeit gemacht? Oder haben die Angst, dass Jigsaw das Redhat-eigene Modulierungsformat ersetzt?

    Grüße

  2. Karla2017-04-23 11:00:00

    Ich stimme TestP zu. Die Punkte hätte man auch schon zu Beginn einreichen können. Es wurden ja auch in X Konferenzen (JavaOne, Devoxx,...) beschrieben was vorhanden ist und was nicht. Nun alle möglichen Features in Jigsaw mit reinzunehmen wäre meines erachtens nicht zielführend. Für mich lebt Java da sich die Apis über Jahre hin entwickeln. Den Versuch OGSI als ein "Standard" zu definieren und auf Jigsaw zu übertragen finde ich schwierig. Das gute an Standards ist, dass es so viele gibt, dass man sich einem aussuchen kann, welcher einen gerade passt.

  3. Kai Hackbarth2017-04-24 15:24:29

    Die Probleme werden seit geraumer Zeit in der Jigsaw Mailingliste diskutiert, scheinen aber nicht zur Zufriedenheit der Java Community berücksichtigt worden zu sein.

    Ich denke, die Probleme komme auch insbesondere daher was Jigsaw eigentlich sein will. Soll es rein für die Modularisierung der JVM genutzt werden oder zur Entwicklung von Anwendungen ??

    Wie funktioniert es mit bestehenden Modulsystemen wie OSGi bzw. mit Java EE, etc. Dies ist bisher nicht praxiserprobt, daher halte ich ein Release von Jigsaw für zu früh.

Schreibe einen Kommentar

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