JCP-EC-Mitglied Werner Keil im Interview

"Der Apache-Rücktritt hätte bereits viel früher erfolgen können"

JAXenter spricht mit Werner Keil, Individual Member des JCP Executive Committee, über die Situation des JCP nach dem Rücktritt der Apache Foundation.

JAXenter: Was bedeutet der Rücktritt der Apache Foundation für den JCP EC?

Werner Keil: Ausgehend von jahrelangen Streitigkeiten und einer Pattsituation, die auch Oracle nach der Übernahme und jüngsten Treffen endgültig zementierte, kann man es nur als logische Schlussfolgerung betrachten. Vermutlich wollten Geir und die Apache Foundation einerseits Oracle eine Chance zur Nachbesserung möglicher Kompromisse bieten, und wurden andererseits wohl durch den Rücktritt von Doug Lea und Tim Peierls motiviert. Meiner Ansicht nach hätte das bereits viel früher erfolgen können, da Apache seit dem Beginn dieses Konflikts nur ganz selten konstruktive Kritik im EC eingebracht hat und auch die Arbeit in etlichen JSRs deutlich unter Motivationsverlust gelitten haben dürfte.

Beispiele wie die mangelnde Adaption von JSR-330 oder CDI sind nur ein Fall. Das gilt auch für Apache-Teilprojekte wie Tapestry, auch wenn hier Anlass zur Hoffnung besteht, dass man in ein paar Versionen vielleicht @Inject von 330 übernehmen könnte.

JAXenter: Wie bewerten Sie das Ergebnis der Wahlen zu den JSRs 334, 335, 336 und 337, die ja den Inhalt vonb JDK7 und JDK8 festlegen?

Werner Keil: Lange überfällig, auch wenn die beiden „Umbrella“ JSRs leider unter dem bekannten Konflikt leiden. Nichtsdestotrotz macht es Sinn, eine logistische Klammer um große Bemühungen wie neue Versionen der Plattform zu haben – ebenso wie es bei Java EE praktiziert wurde und bei früheren SE JSRs. Bei SE 7 ist diese Klammer natürlich deutlich kleiner. Das macht aus Konsequenz aber schon Sinn.

Ich persönlich hätte lieber das bislang informelle „Modularity“ JSR, dem kurioserweise alle Beteiligten damals noch zugestimmt hatten (selbst Apache) unter 334 bis 336 gesehen. Das hätte Java 7 zu 337 gebracht und SE 8 zu 338, statt der „JSR–“ Nummerierung bezogen auf die Version, die sie nun beide haben. Modularität scheint aber, wie auch aus mehreren Kommentaren bei der Abstimmung ersichtlich, noch ein weiterer „Knochen“, an dem sich Oracle die Zähne eher auszubeißen als sie zu schärfen scheint. Der Konflikt zwischen „Jigsaw“ und etablierten Standards wie OSGi wirkt bisweilen so, als würde Jigsaw aus der bekannten Filmreihe „Saw“ höchstpersönlich den Überlebenswillen der Probanden in einer seiner Fallen testen. Dass die Hauptfigur wie berühmte Vorbilder à la Vitruvius oder Da Vinci erfolgreicher Bauingenieur war (engl. „Civil Engineer“), ein Beruf, der mit dem „Software Engineer“ oder Architekten zumindest manche Gemeinsamkeit hat, macht das Beispiel noch interessanter.

Während also jene Teile von Oracle, die aus BEA, NetBeans oder den Entwicklern von Glassfish verblieben, die wenigsten Berührungsängste mit OSGi haben, scheint bei vielen ehemaligen Sun-Mitarbeitern falscher Stolz oft den Blick auf das Wesentliche zu trüben. Das ist nicht das erste Mal und hat schon so manches JSR verhindert oder zumindest erheblich eingeschränkt, das der Sprache und Plattform enorm geholfen hätte. Aus ähnlichen Beweggründen wie bei Jigsaw/OSGi hatte man etwa mit java.util.Logging ein bei Apache bereits bestens etabliertes Framework wie Log4J unnötig kopiert hat, anstatt hier bereits gemeinsame Lösungswege zu suchen. Ein Beispiel, das zeigt, wie manche Konflikte noch viel weiter zurückreichen als 2006, 2007.

Engagierte Spec Leads und Apache-Mitglieder wie Stephen Colebourne haben vorgeschlagen, die Umbrella JSRs stillzulegen und nur technische wie „Coin“, „Lambda“, etc. beizubehalten. Wenn man eine Version wie Java SE 7 als „Distribution“ betrachtet, eher mit Linux vergleichbar, dann würde so ein Vorschlag durchaus Sinn machen. Vor einer Lösung der Modularitätsfrage auf breiter Basis (also wenigstens unter Einbezug aller wesentlichen EC-Vertreter bzw. technisch engagierter JCP-Mitglieder, die damit Erfahrung haben – und nicht bloß einiger weniger Oracle- oder Sun-Mitarbeiter) ist das allerdings kaum sinnvoll. Und ein völlig freies „Bundeling“ lose zusammengewürfelter JSRs würde die Kompatibilität der Plattform tatsächlich in Frage stellen.

Wäre Oracle und der JCP in der Lage, Modularität in akzeptabler und brauchbarer Form zu etablieren, dann käme man einer Art Java-Distribution durchaus näher – ohne die gigantische Menge an Linux-Distributionen, die es heute gibt [1], ernsthaft anzustreben. Diese bauen jedoch auf nur zwei bis drei gängigen Modul- oder Paketsystemen auf. Interessant ist auch, dass Oracles Distribution auf RPM basiert und vollständig kompatibel zu RHEL (Red Hat Enterprise Linux) sein soll. Dies mag helfen, Entscheidungen mancher EC-Mitglieder zu verstehen, zeigt aber auch, dass man trotz heftigen Wettbewerbs in Gebieten wie Java EE Server im Bereich der Standards für Betriebssysteme zumindest bei Linux gemeinsame Grundlagen sucht, letztlich zum Wohl von Entwicklern und Anwendern.

Kommentare

Schreibe einen Kommentar

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