Kolumne: EE Insights

Jakarta EE 8 ante portas: Was es mit dem neuen Spezifikationsprozess auf sich hat

Christian Kaltepoth

Viel tut sich momentan bei der Java Enterprise Edition: der Umzug nach Eclipse, die Umbenennung in Jakarta EE, der neue Community-getriebene Prozess, die Konsolidierung und Weiterentwicklung der Standards. In der neuen Kolumne „EE Insights“ hält uns Christian Kaltepoth auf dem Laufenden und versorgt uns mit Insider-Wissen aus dem Jakarta-EE-Universum.

Christian Kaltepoth

Nach dem Meilenstein ist vor dem Meilenstein. Durch die Veröffentlichung von Eclipse Glassfish 5.1.0 hat das Eclipse-EE4J-Projekt eine erste große Hürde gemeistert. Mit Eclipse Glassfish steht nun ein vollständiger nach Java-EE-8-Kriterien zertifizierter Anwendungsserver zur Verfügung, in den alle unter dem Dach des EE4J-Projekts bei der Eclipse Foundation entwickelten Komponenten eingeflossen sind. Ein großes Unterfangen, welches zugegebenermaßen auch eine Menge Zeit gekostet hat.

Doch das nächste Ziel für Jakarta EE ist bereits gesetzt. Als nächster Meilenstein ist das Release von Jakarta EE 8 geplant. Doch was hat es mit diesem Ziel genau auf sich? Mit Jakarta EE 8 soll ein funktional zu Java EE 8 identischer Stand der Spezifikation unter dem Dach der Eclipse Foundation veröffentlicht werden. Dass es mit dem ersten Release von Jakarta EE keine neue Funktionalität geben wird, mag sicherlich zunächst enttäuschen, hat jedoch einen guten Grund. Jakarta EE 8 wird erstmalig den neuen Jakarta-EE-Spezifikationsprozess verwenden und somit die Rolle des JCP übernehmen. Und gerade das macht Jakarta EE 8 zu einem ganz besonderen Release. Die erste Anwendung des neuen Spezifikationsprozesses wird schließlich zeigen, wie gut er in der Praxis funktioniert und vor allem, ob er die Schwächen des JCP ausgleichen kann. Grund genug, sich den Spezifikationsprozess einmal genauer anzuschauen.

Adieu, JCP! Hallo, EFSP!

Basis für den Jakarta EE Prozess ist der neue Eclipse Foundation Specification Process (EFSP), welcher aktuell in der Version 1.1 vorliegt. Die Versionsnummer lässt vermuten, dass dieser Prozess bereits länger existiert und innerhalb der Eclipse Foundation Anwendung fand. Dem ist allerdings nicht so. Genau genommen ist der EFSP erst wenige Wochen alt und wurde erst ins Leben gerufen, als klar wurde, dass mit Jakarta EE erstmalig Spezifikationen bei der Eclipse Foundation entwickelt werden sollen. Damit aber auch andere Eclipse-Projekte von dem Prozess gebrauch machen können, wurde ein allgemeiner Spezifikationsprozess definiert, der das grundlegende Rahmenwerk für die Entwicklung von Spezifikationen vorgibt. Der Jakarta-EE-Prozess setzt dann auf dem EFSP auf und konkretisiert ihn in einigen Bereichen, wie beispielsweise bezüglich der konkreten Fristen für bestimmte Abstimmungen.

Eine zentrale Rolle im EFSP spielt das sogenannte Specification Committee, welches sich aus den Mitgliedern der Jakarta EE Working Group zusammensetzt. Dabei hat nicht jedes Mitglied auch automatisch eine Garantie auf einen Sitz im Komitee. Lediglich als Strategic Member erhält man garantiert einen Platz. Allerdings ist eine Strategic Membership auch nicht gerade günstig. Die Beiträge sind umsatzabhängig und können bis zu 500.000 $ pro Jahr für die Mitgliedschaft in der Eclipse Foundation und zusätzlich bis zu 300.000 $ pro Jahr für die Mitgliedschaft in der Jakarta EE Working Group betragen. Bei allen anderen Klassen können die Mitglieder einen Kandidaten aufstellen, allerdings werden die doch recht knappen Plätze im Komitee anschließend zwischen den Kandidaten per Wahlverfahren verteilt. Glücklicherweise gilt das auch für Committer Member, sodass die Community auf jeden Fall einen Sitz im Komitee sicher hat. Die Sonderstellung der Strategic Members zeigt sich auch bei den Abstimmungsregeln. Alle durch das Komitee zu treffenden Entscheidungen werden per Zweidrittelmehrheit getroffen, müssen aber auch eine Zweidrittelmehrheit der Strategic Member beinhalten.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

Specifiation Projects = JSR

Der Eclipse Foundation Specification Process führt außerdem eine neue Art von Projekt ein, nämlich die sogenannten Specification Projects. Streng genommen sind Spezifikationsprojekte spezielle Eclipse Projekte, die zusätzlich dem Specification Committee unterstehen. Ähnlich zu normalen Projekte haben auch Spezifikationsprojekte einen genau definierten Scope, welcher das Arbeitsfeld genau festlegt. Das Hauptziel eines solchen Projektes ist die Erarbeitung einer Specification. In gewisser Weise ist ein Spezifikationsprojekt somit das Äquivalent zu einem Java Specification Request (JSR) nach den Java Community Process (JCP) Regeln. Eine konkrete Version der Spezifikation muss immer aus einem Spezifikationsdokument, dem Technology Compatibility Kit (TCK) zur Prüfung der Kompatibilität einer Implementierung mit der Spezifikation und mindestens einer Compatible Implementation bestehen. Das Konzept der TCKs ist ebenfalls aus dem JCP bekannt und hat auch weiterhin eine zentrale Bedeutung, da nur mithilfe eines TCKs Implementierungen objektive geprüft werden können.

Die Anforderung an mindestens eine Compatible Implementation ersetzt die altbekannte Referenzimplementierung (RI). Die wesentliche Änderung im Vergleich zum JCP ist somit, dass es keine Implementierung mit einer Sonderrolle mehr gibt. In der Vergangenheit wurde die Referenzimplementierung häufig herangezogen, wenn eine Spezifikation einen gewissen Aspekt nicht klar definiert hat. Das Verhalten der Referenzimplementierung wurde dann oft als das eigentlich durch die Spezifikation gewünschte Verhalten definiert, was sicherlich nicht immer stimmte. Indem man von vorneherein alle Implementierungen gleich stellt, wird diese Argumentation nun nicht mehr möglich sein. Trotzdem liegt die Vermutung nahe, dass es in den meisten Fällen erst einmal bei einer Implementierung bleiben wird, die als Bestandteil einer Spezifikationsversion veröffentlicht wird.

Alle wichtigen Ereignisse im Lebenszyklus einer Spezifikation bzw. deren Versionen werden durch eine Abstimmung des Specification Committees ratifiziert. Für die Spezifikationen ist das vor allem das sogenannte Creation Review, welches Voraussetzung für die Erstellung eines neuen Spezifikationsprojekts ist. Interessanter sind allerdings die Lebensphasen einer konkreten Spezifikationsversion. Bevor das Projektteam einer Spezifikation mit der Arbeit an einer neuen Version beginnt, gilt es einen sogenannten Release Plan zu erstellen. Wie der Name bereits vermuten lässt, handelt es sich hierbei um eine Beschreibung der Themen, die sich das Projektteam für die nächste Version als Ziel gesetzt hat. Außerdem sollte der Release Plan bereits einen groben Zeitplan enthalten und beschreiben, wie die konkreten Meilensteine auf dem Weg zur neuen Version aussehen werden. Der Release Plan wird dem Specification Committee vorgelegt und mit den bereits beschriebenen Abstimmungsregeln genehmigt. Bis zur Abstimmung ist es natürlich sowohl dem Specification Committee, als auch der Community möglich, Feedback zum Release Plan zu geben und somit Einfluss auf diesen zu nehmen.

Von der Theorie zur Praxis: Die Entwicklungsphase & das Release Review

In der aktiven Entwicklungsphase muss ein Spezifikationsprojekt mindestens einmal im Jahr einen Milestone veröffentlichen. Dieser Milestone bildet die Grundlage für die Progress Reviews. Im Rahmen dieses Reviews prüft das Specification Committee, ob die Arbeit auf dem richtigen Weg ist, die durch die Eclipse Foundation definierten Regeln bezüglich des geistigen Eigentums eingehalten wurden und prüft auf eventuelle Schwächen bezüglich der Qualität und Architektur. Auch dieses Review wird wieder per Zweidrittelmehrheit entschieden. Ist die Abstimmung erfolgreich, kann die Arbeit des Projektteams in die nächste Phase gehen.

Kommt das Projektteam an den Punkt, an dem es alle Arbeiten beendet hat und den aktuellen Stand veröffentlichen möchte, beginnt die wichtigste Phase im Leben einer Spezifikationsversion. Im sogenannten Release Review wird entschieden, ob die neue Version allen Ansprüchen genügt und sich offiziell als Jakarta-EE-Spezifikation bezeichnen kann. Wie nicht anders zu erwarten, hat dieses Review die strengsten Auflagen. So muss das Projektteam beispielsweise glaubhaft machen, dass das TCK vollständig und dafür geeignet ist, Implementierungen der Spezifikation korrekt zu validieren. Ebenso ist das Projektteam verpflichtet, mindestens eine Compatible Implementation zu liefern, welche die entsprechende Version des TCKs besteht. Die Veröffentlichung der Spezifikation muss sowohl vom Jakarta EE Specification Committee, als auch vom Eclipse EE4J Project Management Committee (PMC) und vom Eclipse Management Office (EMO) jeweils per Zweidrittelmehrheit genehmigt werden. Was nach sehr viel Bürokratie klingt, ist aber sicherlich notwendig, um die geforderten Qualitätsrichtlinien für eine Jakarta-EE-Spezifikation zu erfüllen.

Fazit

Betrachtet man die verschiedenen Phasen der Entwicklung einer Spezifikation, so lassen sich doch schnell deutliche Ähnlichkeiten zum JCP erkennen. Das Plan Review entspricht grob der JSR Review Phase und die regelmäßigen Progress Reviews erfüllen dieselbe Rolle, wie die vom JCP geforderten Phasen Early Draft Review, Public Review, etc. Und während im EFSP das Specification Committee die meisten wichtigen Entscheidungen trifft, war es im JCP das Executive Committee (EC), welches diese Rolle übernahm.

An dieser Stelle sei noch einmal betont, dass die bisher beschriebenen Regeln durch den Eclipse Foundation Specification Process definiert werden, welcher für den Jakarta EE Specification Process lediglich das Rahmenwerk vorgibt. Allerdings sieht es aktuell so aus, als würde der Jakarta-EE-Prozess nur die Länge der Zeiträume für die Abstimmungen und einige weitere Details festlegen. Allzu viele Änderungen am eigentlichen Basisprozess sind somit nicht zu erwarten.

Insgesamt wirkt die Art und Weise, in der zukünftig Jakarta-EE-Spezifikationen entwickelt werden, gut durchdacht und praxistauglich. Ob die viel zitierten Schwächen des JCPs ausgeglichen werden, wird sich noch zeigen. Zwar wird seitens der Eclipse Foundation immer wieder betont, dass es doch deutliche Unterschiede zum JCP gibt, wie beispielsweise „Code First“ statt „Specification First“, sowie Open-Source-Lizenzen für Spezifikationen und TCKs, allerdings darf man dabei nicht vergessen, dass dies im JCP teilweise nicht anders war. So hat Red Hat mit CDI und Bean Validation bereits seit vielen Jahren Spezifikationen im Rahmen des JCP entwickelt und dabei die liberale Apache-2.0-Lizenz verwendet. Und besonders die erfolgreichsten Spezifikationen, wie beispielsweise CDI und die ersten JPA-Versionen, haben schon immer nach dem „Code-First“-Prinzip gearbeitet, was meiner Meinung nach einer der Hauptgründe für deren Erfolg war. Die Kritikpunkte am JCP beziehen sich daher häufig eher auf die von Oracle geleiteten JSRs und weniger auf den JCP selbst.

Wir dürfen also gespannt sein, wie es mit Jakarta EE weitergeht. Einen genauen Zeitplan für Jakarta EE 8 gibt es bisher nicht. Aber man darf optimistisch sein, dass die Community nicht mehr allzu lange auf das erste Jakarta EE Release warten muss.

Geschrieben von
Christian Kaltepoth
Christian Kaltepoth
Christian Kaltepoth arbeitet als Senior Developer bei ingenit GmbH & Co. KG in Dortmund. Sein Schwerpunkt ist die Entwicklung von webbasierten Unternehmensanwendungen auf Basis von Java-EE-Technologien. Darüber hinaus ist er in mehreren Open-Source-Projekten wie Apache DeltaSpike, Rewrite, PrettyFaces und Togglz aktiv. Er ist Mitglied der JSR 371 Expert Group und ein regelmäßiger Sprecher auf Konferenzen.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Jakarta EE 8 ante portas: Was es mit dem neuen Spezifikationsprozess auf sich hat"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

Hi, das klingt alles sehr bürokratisch.

MfG