Christoph Engelbert über Hazelcasts Position in der Jigsaw-Abstimmung

Java 9 vor der Entscheidung: „Es werden noch einige JCP Executive Member gegen Jigsaw stimmen“ [Interview]

Hartmut Schlosser

(c) Shutterstock / Hayati Kayhan

Wie geht es weiter mit Java 9? Trotz der Experten-Kritik am Modulsystem Jigsaw hat Oracle die Abstimmung darüber eingeleitet. Red Hat und IBM haben bereits angekündigt, mit „Nein“ zu stimmen. Im Interview verrät uns Christoph Engelbert, Vertreter von Hazelcast im JCP-Exekutiv-Komitee, warum auch Hazelcast den aktuellen Jigsaw-Entwurf nicht unterstützen wird.

Java 9 und die Jigsaw-Abstimmung – Hintergründe

Wir haben bereits darüber berichtet: Oracle hat das Exekutiv-Komitee des JCP (Java Community Process) zur Abstimmung über den Entwurf des Java-9-Modulsystems (JPMS – JSR 376) aufgerufen. Bis zum 8. Mai sollen die 23 Unternehmensvertreter und individuellen Mitglieder des Exekutiv-Komitees im sogenannten „Public Review Ballot“ über die Annahme des JSR 376 abstimmen.

Nach der offiziellen Ankündigung von Red Hat und IBM, in der Public Review Ballot mit „Nein“ zu stimmen, stellt sich nun die spannende Frage, wie sich die anderen Mitglieder des Exekutiv-Komitees verhalten werden. Im Hintergrund steht der fehlende Konsens innerhalb der JPMS-Expertengruppe über einige technische Entscheidungen bzgl. der Jigsaw-Spezifikation und die Forderung von Red Hat, Apache Maven und anderen, Java 9 nötigenfalls nochmals zu verschieben.

Christoph Engelbert vertritt Hazelcast im JCP-Exekutiv-Komitee und wird ebenfalls an der Abstimmung teilnehmen. Im Gespräch mit JAXenter klärt er uns über den aktuellen Stand auf und stellt seine eigene Position in der Debatte heraus.

Die Kritik an Jigsaw – was ist dran?

JAXenter: Das Modul-System Jigsaw steht momentan in Kritik. Red Hat und IBM haben bereits angekündigt, in der laufenden Abstimmung über die JPMS Public Review mit „Nein“ zu stimmen. Was ist der Hintergrund?

Vorgebrachte Probleme mit Jigsaw wurden teilweise von Oracle abgeschmettert.

Christoph Engelbert: Aus meiner Sicht gibt es mehrere Gründe, warum die beiden Firmen gegen das JPMS stimmen wollen. Der größte Punkt ist sicher der fehlende Konsensus innerhalb der Expert Group (EG). Vorgebrachte Probleme wurden teilweise von Oracle abgeschmettert und als ungültig zurückgewiesen. Viele dieser Punkte betreffen tatsächlich den JVM-internen Use Case nicht, aber entsprechende externe Bibliotheken oder Frameworks.

Andere Gründe gehen auf die oben genannten „abgewiesenen“ Probleme zurück und beziehen sich auf einige technische Entscheidungen. Ein Beispiel ist die Frage, weshalb die Modul-Metadaten als Bytecode gespeichert sind, anstatt sie, wie bei OSGi, im MANIFEST zu hinterlegen.

JAXenter: Kannst du die technischen Kritikpunkte nachvollziehen? Was sind aus deiner Sicht die wichtigsten Argumente gegen den aktuellen Jigsaw-Entwurf.

Christoph Engelbert: Zum Teil kann ich sie nachvollziehen, zum Teil sind es aber auch sehr tiefe Probleme, an denen man vermutlich nur vorbeikommt, wenn man einen speziellen Fall implementieren will. Hier ist dann auch mein Verständnis vorbei, und ich muss den Anmerkungen der Community und anderen EG-Mitgliedern vertrauen.

Ich denke aber, dass es extrem unbefriedigend und auch gefährlich ist, wenn Mitglieder einer Expertengruppe nicht als vollwertige Mitglieder gewertet werden, zumindest sieht es in diesem Fall so aus.

Weiterhin gibt es viele Diskussionen um die Namenskonventionen von Modulen. So ist z.B. explizit verboten, dass Modulnamen typische Versionsnummer-Pattern (wie z.B. 2.0.0) erhalten. Offizielle Begründung ist, dass Modulnamen als Java-Identifier darstellbar sein sollen. Doch dies ist meiner Meinung nach nur dem Umstand geschuldet, dass Module in Bytecode kompiliert werden.

Auch abseits davon gibt es immer noch viele Probleme, die nicht wirklich gelöst sind. Dafür gibt es dann zwar den Parameter —permit-illegal-access, den man nutzen kann.  Dieser wirft dann aber wieder jede Menge Warnungen ins Logfile. Diese Warnungen werden selbstverständlich von Kundenseite nicht an Oracle herangetragen, sondern z.B. an Hazelcast. Ich sehe da Aussagen wie “Was habt ihr gemacht? Wieso ist das jetzt kaputt” auf unser Supportteam zukommen.

Lesen Sie auch: Oracle plant den „Java 9 Kill-Schalter“

Mein größtes, persönliches Problem ist aber die Art und Weise, wie das JPMS dargestellt wird. Es hilft den meisten Anwendungen und Bibliotheken nicht weiter. Multi-Release JARs – also JARs, die unter Java 8 und 9 laufen – sind unnötige Komplikationen beim Build-Prozess. Zum Schluss ist das Feature, das alle glauben zu bekommen, nämlich Multi-Versions-Support, nicht Teil von Jigsaw.

Ein gutes Beispiel für den letzten Punkt ist direkt bei Euch auf JAXenter zu finden. Ein Kommentator hatte einen der Vorteile von Jigsaw folgendermaßen beschrieben:  „Man kann jetzt auch mehrere Versionen einer Bibliothek laden, ohne dass diese sich ins Gehege kommen.” Das glauben viele, ist so aber leider nicht zutreffend.

Oracles Haltung in der Debatte

JAXenter: Mark Reinholds Position scheint zu sein, dass die jetzt diskutierten Ziele für Jigsaw so gar nicht vorgesehen waren. Auf der Mailing-Liste schreibt er:

„We do not have consensus in this EG on moving forward to Public Review. That is only because some members continue to insist that we must address goals that were neither mentioned in the original JSR submission nor recorded in the agreed requirements.“

Was denkst du darüber?

Christoph Engelbert: Ich denke, die Frage ist einfach zu beantworten. Man könnte einfach die Wayback Machine nutzen und sich alte Versionen der Requirements anschauen. Generell kann ich hier, ohne mich auf dünnes Eis zu begeben, aber nur wenig dazu sagen. Ich glaube an das Gute im Menschen und würde jetzt sagen, dass diese Requirements vor 12 Jahren wirklich noch nicht existierten 😉

Gut, dass sich die Welt in der Zeit nicht weitergedreht hat.

JAXenter: Auf jeden Fall kommt die Kritik spät – wir stehen ja 3 Monate vor dem geplanten Java 9 Release. Einige der Punkte wurden auch schon in der Expertengruppe diskutiert – und es wurde eine andere Entscheidung gefällt. Könnte man nicht sagen, dass IBM, RedHat, Maven & Co. sich als schlechte Verlierer aufführen und damit dem gesamten Projekt Java 9 schaden?

Christoph Engelbert: Es ist ja nicht so, dass diese Probleme erst seit wenigen Monaten diskutiert werden. Alleine die Versuche, die größten Probleme in Bibliotheken wie ByteBuddy oder Mocking Frameworks zu fixen, dauern seit einer gefühlten Ewigkeit an.

Ob IBM und Konsorten hier als schlechte Verlierer auftreten? Ich glaube nicht. Viele der angesprochenen Punkte sind Real-World-Probleme und müssen angesprochen werden. Das große Problem mit dem JPMS ist, dass es nicht nur einen kleinen, begrenzten Rahmen betrifft, sondern tatsächlich nahezu jede Anwendung. Viele der Änderungen sind extrem einschneidend und bringen entsprechende Einschränkungen mit sich.

Ein Beispiel: Eine kleine Änderung betrifft das dynamisches Anhängen eines Java Agent, das nicht mehr ohne weiteres möglich sein sollte. Damit wären die meisten Debugging / Tracing Tools zumindest teilweise nutzlos geworden. Diese Änderung wurde allerdings ausgiebig diskutiert, und mit dem Ergebnis können die meisten leben.

Generell stimmt es aber: Die Diskussion ist extrem spät laut geworden, da bis dahin vermutlich jeder gehofft hat, dass sich Oracle noch einlenken lässt. Ich denke also, hier liegt die Verantwortung durchaus auf beiden Seiten.

Was bedeutet das für Java 9?

JAXenter: Wie sollte es denn jetzt aus deiner Sicht weiter gehen? Java 9 verschieben und Jigsaw anpassen? Oder den Release-Termin halten und die bis dahin möglichen Anpassungen an Jigsaw vornehmen? Oder was ganz anderes?

Ich denke, es werden noch einige JCP Executive Member gegen JSR 376 voten, inklusive wir.

Christoph Engelbert: Die vermutlich schwierigste Frage. Ich denke, es werden noch einige JCP Executive Member gegen JSR 376 voten, inklusive wir. Der aktuelle Stand ist extrem schwierig. Ich habe das Thema mit einigen interessierten Leuten aus der deutschsprachigen Java Community diskutiert. Da wir seit kurzem ein Slack-Team für eben diese Community haben, war es relativ einfach, entsprechende Leute zusammen zu bringen.

Wie es weitergehen könnte, ist nicht so einfach vorauszusehen. Sollte der EC Vote durchgehen, dann wird JSR 376 in der jetzigen Form kommen. Wird die Abstimmung negativ ausfallen, dann kann nachgearbeitet werden, was sich aber auf den Release-Termin auswirken wird. Um Jigsaw wieder auszubauen, wird sicher keine Zeit mehr sein, ergo “muss” es auf die eine oder andere Art kommen.

Die entscheidende Frage wird sein, wie sich Oracle nach einer negativen Abstimmung verhalten wird. Hoffen wir das Beste 🙂

Für alle, die sich an der Diskussion beteiligen möchten: Das oben genannte Slack-Team steht jedem offen, der sich für Java, die JVM oder andere JVM-basierte Sprachen interessiert. Dort werden viele Themen um die Zukunft von Java, aber auch um Frameworks diskutiert, und jeder ist eingeladen. Einen Invite kann sich jeder selber unter http://bit.ly/jvmg-invite erstellen.

JAXenter: Vielen Dank für dieses Interview!

Christoph Engelbert is the Technical Evangelist and Senior Solutions Architect at Hazelcast. He’s also an Apache Committer and Open Source enthusiast, and is mostly interested in Performance Optimizations and understanding the internals of the JVM and the Garbage Collector.

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
  1. TestP2017-05-04 12:24:59

    Ja, dass man mehrere Versionen eines Modul getrennt benutzen kann, ohne dass diese sich irgendwie in die Quere kommen da lag ich tatsächlich daneben. Danke für die Klarstellung. Unter diesen Umständen ist der Nutzen von Jigsaw eher fragwürdig und schafft wohl beträchtlich mehr Probleme als es Nutzen bringt. Da einfach nicht ordentlich zu Ende gedacht.

    Grüße

  2. Chris Engelbert2017-05-06 10:11:26

    Hey @TestP,

    sorry, dass ich deinen Kommentar mit in das Interview gezogen habe. Es war nur ein sehr gutes Beispiel. Keine Sorge, du bist nicht der Einzige, der erwartet hat, dass dieses Problem gelöst wird. Es ist nur verständlich, dass diese Erwartungshaltung entsteht. Zwar wird immer wieder betont "wir haben nie gesagt wir lösen Multi-Version Probleme", aber zwischen "nicht sagen" und Aussagen wie "wir werden das Multi-Version Problem definitiv nicht mit dieser Version lösen" sind halt himmelweite Unterschiede :-)

    Und auch die Reaktion sehe ich oft: "Wie kommt nicht? Hm, ok dann bringt es vermutlich mehr Probleme als Nutzen".

    Ich denke das große Problem ist wirklich die Art und Weise wie es verkauft wird. Es ist nett und für das JDK super, aber derzeit hat es nur Nice-To-Have Features für Lib-Entwickler, vielleicht ein paar nützliche Dinge für App-Entwickler, besonders bei Monolithen (aber wer baut heute schon noch sowas ;-)).

  3. [Java 9] Jigsaw wurde abgelehnt - JuKuSoft2017-05-10 17:06:26

    […] die Unausgereiftheit dieses JSRs. Schon im Vorfeld hatten Firmen wie IBM, Red Hat oder Hazelcast angekündigt, gegen Jigsaw zu […]

Schreibe einen Kommentar

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