Suche
Was das Exekutiv-Komitee des Java Community Process diskutiert

Klartext im JCP-Meeting: „Oracle soll die Führung übernehmen oder den Weg freimachen“

Hartmut Schlosser

(c) Shutterstock / 0beron

Zweimal pro Jahr kommt das Exekutiv-Komitee des Java Community Process zu einem Face-to-Face-Meeting zusammen. Im jüngsten Treffen wurden einige durchaus brisante Themen besprochen: die wackelige Zukunft von Java ME, agilere JCP-Prozesse und die Konkurrenzsituation zwischen Java EE und MicroProfile.io.

Das Treffen, das vom 10. bis 11. Januar in London stattfand, begann mit einer Personalie: Oracles JCP-Chairman Patrick Curran wird sich im Februar in den Ruhestand verabschieden. 15 Jahre lang hat Curran bei Sun, dann bei Oracle an der Standardisierung von Java mitgewirkt, 10 Jahre war er im JCP als Chairman vertreten. Nun wird Heather Vancura von Oracle nachrücken, die bereits das nächste JCP-Treffen am 17. Februar 2017 leiten wird.

Wir gesund ist der JCP?

Wir starten mit einigen Zahlen. Im JCP-Jahresbericht kam zum Vorschein, dass 2016 nur 18 aktive JSRs zu verzeichnen hatte. Das ist im Vergleich zum Vorjahr mit seinen 30 aktiven JSRs signifikant weniger. Bei 12 der 18 aktiven JSRs stellt Oracle den Spec Lead.

Bildschirmfoto 2017-01-25 um 12.19.25

Übersicht JSR-Aktivitäten (Quelle: 2016 Year End Summary, Heather VanCura)

Die Zahl der JCP-Mitglieder stieg indes um 35% auf 1213. In Anbetracht der fallenden Zahlen seit 2014 ist damit aber lediglich eine Trendwende gelungen, wie die Statistik aus der Präsentation von Heather VanCura zeigt:

Bildschirmfoto 2017-01-25 um 12.18.25

Entwicklung der JCP-Mitgliedszahlen (Quelle: 2016 Year End Summary, Heather VanCura)

Kann man dem JCP mit diesen Werten einen guten Zustand attestieren? Die Teilnehmer am JCP Meeting zeigten hier offenbar unterschiedliche Meinungen.

Die wackelige Zukunft von Java ME

So bemängelte Leonardo Lima (V2COM) den Stillstand bei der Java ME (Micro Edition), der ihn an das letztjährige Schweigen Oracles zu Java EE erinnere. Obwohl die Wichtigkeit von Java ME für IoT-Anwendungen in zurückliegenden JavaOne-Konferenzen mit zu den Hype-Themen überhaupt gehörte (wir berichteten), war auf der JavaOne 2016 tatsächlich nur wenig dazu zu hören. Auch keine neuen JSRs für Java ME gab es im letzten Jahr.

Hier griff Mike Milinkovich, Exekutiv-Direktor der Eclipse Foundation, in die Diskussion ein, der mit dem breiten Portfolio an IoT-Projekten bei Eclipse dem Thema ein besonderes Gewicht einräumt. Oracle selbst scheine am Internet der Dinge indes das Interesse verloren zu haben. Das Problem ist nun, dass nur Oracle ein Platform oder Profile JSR leiten kann, es also anderen interessierten Parteien, wie etwa Gemalto, nicht möglich ist, die Führung zu übernehmen.

Mike Milinkovichs Aussage dazu war eindeutlig: Oracle solle entweder führen oder den Weg freimachen:

Oracle should either lead or get out of the way.

Vermittelnd schlug Martijn Verburg vor, eine Arbeitsgruppe zum Thema Java ME zu bilden, um Oracle konkrete Vorschläge für das weitere Vorgehen zu unterbreiten. Denn: „If we fail in this space Java will lose to JavaScript.“

Interesse an der Beteiligung an einer solchen Arbeitsgruppe zeigten Mike Milinkovich, V2COM, the London Java Community, MicroDoc und Werner Keil – möglich also, dass 2017 wieder etwas mehr Bewegung in den JavaME/Embedded/IoT-Bereich kommt.

JCP.next und das Dilemma um die TCKs

Bereits im April 2016 hatte das Exekutiv-Komitee eine Anpassung der JCP-Regelungen beschlossen. Eine Arbeitsgruppe sollte sich mit der Ausarbeitung eines entsprechenden JSRs für ein JCP.next-Prozessdokument befassen. Ein wichtiges Anliegen ist hier, den Zugriff auf die TCKs zu erweitern, also auf die sogenannten Technology Compatibility Kits, welche sicherstellen, das die Implementierung eines Java-Standards auch der Spezifikation entspricht.

Das Problem ist hier, dass selbst Expertengruppen bis zum finalen Release eines JSR nicht immer Zugriff auf das TCK erhalten. Auch nach dem Release werden TCKs von Oracle nur an Lizenznehmer ausgeliefert, sodass, wie Oliver Gierke es hier auf JAXenter einmal im Interview ausgedrückt hat, „man faktisch ins Blaue entwickelt“:

Die Expert Group hat bis zum finalen Release des JSR keinen Zugriff auf das TCK. Diesen bekommen auch nach dem Release auch nur Lizenznehmer. Zu diesem Zeitpunkt ist der JSR jedoch bereits komplett verabschiedet, und Probleme im TCK sind schwer zu identifizieren. Es gibt nur einen sehr vagen Rückkanal für Feedback: eine Email an den Speclead.

Im JCP Meeting äußerte deshalb David Blevins von Tomitribe den Wunsch, schon im Spezifizierungsprozess Zugriff auf verfügbare TCKs zu erhalten. Da Oracle diese allerdings auch weiterhin nicht Open Source zur Verfügung stellt, besteht der Kompromiss vorläufig darin, dass alle JSRs TCK-Lizenzen bereitstellen sollten, um das TCK zumindest Entwicklern der zugehörigen Referenzimplementierung zugänglich zu machen.

Allerdings dauert es in der Praxis sehr lange, bis Oracle solche Lizenzen tatsächlich signiert, und auch ein TCK für Java 9 ist bisher lediglich für Lizenznehmer verfügbar. Für Java ME scheint zudem das von Gierke beschriebene Szenario zu gelten, dass nämlich selbst die Expertengruppe keinen Zugriff auf das TCK hat, wie Werner Keil im JCP Meeting kommentierte.

Patrick Currans Antwort auf das TCK-Dilemma bestand darin, im neuen JCP.next-Prozessdokument entsprechende Anforderungen als verbindlich aufzunehmen, um diese Probleme zu beheben.

Java EE versus MicroProfile – Standard versus Innovation?

Der Hintergrund für die MicroProfile.io-Initiative dürfte den meisten Lesern geläufig sein: Nachdem Oracle sich 2016 lange nicht zur Zukunft von Java EE geäußert hatte, hatten RedHat, IBM, Tomitribe, Payara, LJC und andere unter dem Namen MicroProfile.io eine Untermenge an Java-EE-Technologien für die Entwicklung von Microservices-Anwendungen vorgestellt.

Nun hat sich Oracle nach der JavaOne 2016 für die Java Enterprise Edition ebenfalls in Richtung Cloud und Microservices bewegt. Wie stehen die beiden Projekte also zueinander?

Interessanterweise formulierte Tim Ellisons von IBM das Ziel von MicroProfile.io, einen Inkubator für innovative Technologien in den Bereichen Enterprise Java und Microservices bereit zu stellen. Wichtig dabei: Schlußendlich gehe es auch darum,  erfolgreiche, bewährte Technologien aus dem Inkubator in einen, so wörtlich, „passenden Standardisierungskörper wie den JCP einzubringen.“

MicroProfile.io, das mittlerweile die Version 1.0 verabschiedet und seine Heimat als offizielles Eclipse-Projekt gefunden hat, soll im Jahr 2017 nun vierteljährliche, iterative Releases bereit stellen. Hier sei jeder, explizit auch Oracle, eingeladen, sich an der Weiterentwicklung zu beteiligen.

David Blevins präzisierte, dass sich Eclipse MicroProfile nicht als Konkurrenz zum Java-EE-Standard sehe. Eher gehe es darum, im Vorfeld einer Standardisierung für die Allgemeinheit nützliche APIs zu finden. Laut Blevins ist es allerdings noch zu früh, dafür einen offiziellen JSR einzureichen, da bislang weder ausreichend API-Code geschrieben, noch eine Übereinkunft getroffen wurde, welche Konfigurations-Features nötig sind:

It would be premature to standardize now.

Um die Wichtigkeit der MicroProfile-Initiative zu unterstreichen, verwies Blevins auf die eingangs erwähnten zurückgehenden aktiven JSRs: Wenn es in Zukunft mehr als 10 aktive JSRs geben soll, dann ist mehr Innovation nötig, so Blevins. Die niedrige Zahl der aktiven JSRs zeige, dass der JCP derzeit noch kein ausgewogenes Maß zwischen Innovation und Standardisierung gefunden habe.

Klartext

Im JCP Meeting wurde also durchaus Klartext geredet. Ob den Worten nun auch Taten folgen, wird mit Spannung zu beobachten sein. Über die weiteren Themen des Meetings, etwa eine Standardisierung des NoSQL-Bereiches, den Zustand von JSF und den Vorschlag, Inkubator-Module für das JDK zu ermöglichen, können sich Interessierte in den öffentlichen Meeting Minutes unterrichten.

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. Jörg2017-01-26 16:29:51

    Danke für den Artikel.
    Was JavaSE betrifft, kann es auch sein, dass vielfach alte JSRs einfach ein Maintenance Update bekommen haben oder Neuerungen ohne JCP mittels JEPs vorangetrieben werden - beispielsweise JEP 222 jshell - s.a. http://openjdk.java.net/jeps/0 und Abschnitt "An eyebrow-raising approach" aus dem Artikel https://jaxenter.com/jshell-the-java-9-repl-what-does-it-do-120299.html von Werner Keil (JCP Kommitteemitglied).

    Grüße

Schreibe einen Kommentar

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