Suche
Kolumne: EE Insights

Die Zukunft von Enterprise Java: Quo vadis, Jakarta EE?

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

Die Arbeit an Jakarta EE nimmt langsam Fahrt auf. In Kürze ist der erste wichtige Meilenstein geplant: Mit Eclipse Glassfish 5.1 veröffentlicht das Eclipse-EE4J-Projekt einen vollständig nach Java-EE-8-Regeln zertifizierten Applikationsserver. Dieses Release ist eine wichtige Vorstufe für das eigentliche Ziel, die Veröffentlichung von Jakarta EE 8, der ersten eigenständigen Version von Jakarta EE. Geplant ist aktuell, dass dieses erste Jakarta EE Release funktional den gleichen Stand wie Java EE 8 haben soll. Aber so richtig spannend wird es natürlich erst bei den darauffolgenden Veröffentlichungen. Wo will Jakarta EE hin? Was steht in der Zukunft im Fokus?

Jakarta EE – Die Agenda

Um diese Fragen zu beantworten, hat das EE4J PMC vor Kurzem ein Dokument mit dem Titel EE4J Projects – Technical Direction veröffentlicht. Ganz neu ist das Dokument allerdings nicht. Den ersten Entwurf hat das PMC bereits im Juni als Vorabversion zur Verfügung gestellt und um Feedback der Community gebeten, das in den darauffolgenden Wochen eingearbeitet wurde. Da dieses Dokument in gewisser Weise als Grundlage für die weitere Ausrichtung von Jakarta EE dient, lohnt es sich, einen genaueren Blick darauf zu werfen.

Bereits die Einleitung bringt die Grundidee von Jakarta EE auf den Punkt:

Jakarta EE is the future of cloud-native Java. Jakarta EE’s mission is to provide frequent releases, lower barriers to participation, and to put the community back into what was formerly the Java EE platform.

Das Wort „Cloud“ fällt dabei natürlich direkt ins Auge. Aber die Ausrichtung auf Cloud-Architekturen sollte nicht allzu überraschend sein, hat sich doch die Cloud als Sinnbild für moderne, flexible und skalierbare Architekturen inzwischen in den Köpfen aller festgesetzt. Die Punkte „häufige Releases“ und „Teilhabe der Community“ betonen, dass man aus den Fehlern von Java EE gelernt hat. So war dessen Release-Zyklus und die Möglichkeiten der Community, an den Standarisierungsprozessen teilzunehmen, schon seit je her ein großer Kritikpunkt. Offensichtlich versucht man mit Jakarta EE hier, einen deutlich anderen Weg zu gehen.

Im Abschnitt „Open for Innovation“ heißt es dann:

As Jakarta EE evolves we expect innovation from a range of open source communities to be quickly adopted into new versions of the platform to help developers create portable cloud-native applications.

Diese Aussage kann man schon fast als offizielle Einladung verstehen. Es wird explizit darauf hingewiesen, dass Innovationen aus allen Communitys herzlich willkommen sind. Sei es von der Apache Software Foundation, der Spring Community, der MicroProfile-Initiative oder aus anderen Richtungen. Mich persönlich würde es beispielweise sehr freuen, mehr Feedback von der Spring Community zu erhalten. Das Spring-Ökosystem ist schon viele Jahre ein Inkubator für innovative Technologien und daher der perfekte Kandidat, wenn es um Inspiration für Jakarta EE geht.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

Testen, bitte!

Der nächste Abschnitt des Dokuments beschäftigt sich mit dem TCK. Das „Technology Compatibility Kit“ wurde genau wie viele andere Projekte bereits zur Eclipse Foundation übertragen und wird verwendet, um die Kompatibilität einer Java-EE-Implementierung mit den Spezifikationen zu validieren.

Unter der Überschrift „Split stand-alone Jakarta EE TCK into individual projects“ heißt es:

Each API project should have a corresponding TCK test repository project. […] All projects have to use the same standard mechanism for TCK. […] It will require some PMC guidance and community input about how new TCK tests are organized, what testing frameworks are used, etc.

Um diesen Punkt zu verstehen, muss man betrachten, wie das TCK bisher organisiert wurde. Jede im Rahmen des JCP entwickelte Spezifikation ist verpflichtet, eine Test-Suite zur Prüfung der Kompatibilität zu erstellen. Java EE besteht aus über 25 Spezifikationen, deren TCKs in einem einzelnen großen Java EE TCK (auch als CTS bezeichnet) zusammengefasst werden.

Das Java EE TCK wurde als einzelnes Projekt an die Eclipse Foundation übertragen. Für den eigentlichen Transfer war das sicherlich sinnvoll, vor allem, um den Aufwand gering zu halten. Für die Zukunft wäre es aber sicherlich sinnvoller, wenn der Quellcode des TCKs in den Repositorys der einzelnen Spezifikationen gepflegt werden würde. Jedes Spezifikationsprojekt wäre dann für das eigene TCK zuständig und würde es bei Änderungen an der Spezifikation entsprechend anpassen können.

Damit das Ganze nicht im Chaos endet, ergibt es aber natürlich trotzdem Sinn, sich auf einen einheitlichen Rahmen bezüglich der Organisation der TCKs zu einigen. Ich persönlich hoffe, dass die Gelegenheit genutzt wird das TCK auch etwas zu modernisieren. Dazu muss man wissen, dass das TCK eine über viele Jahre gewachsene Code-Basis mit über 4,6 Millionen Zeilen Quellcode ist. Moderne Testframeworks wie beispielsweise Arquillian sucht man hier vergeblich. Wie man aus den Refactorings großer Projekte kennt, hilft hier sicherlich nur eine Verbesserung in vielen kleinen Schritten.

Modernisierung der Plattform

Im nächsten Abschnitt wird die Unterstützung neuerer Features aus aktuellen JDK-Versionen angesprochen:

Despite the fact that the first release of Jakarta EE will be JDK8 based, projects should start preparation for the module system, i.e. JDK9+ support. […] The global definition and usage of modules needs to be defined at the Platform level (PMC), again with community input, and then adhered to by the various EE4J component projects.

Dieser Schritt ist mit Sicherheit sehr sinnvoll. Das Thema Modularisierung hat Java EE ohne ein Modulsystem im JDK bereits vor vielen Jahren selbst angehen müssen. Dabei sind verschiedenste Typen von Deployment-Artefakten (WAR, EAR, RAR, etc.) und Konzepte wie hierarchische ClassLoader herausgekommen. Hier stellt sich natürlich die Frage, wie Jakarta EE in Zukunft seinen Nutzen aus dem JDK-eigenen Modulsystem ziehen kann. Aber das wird sicherlich ein Thema sein, welches erst in einiger Zeit angegangen wird.

Was unter der Überschrift „Standardise on the Maven build system“ beschrieben wird, kann man sich vermutlich schon fast denken:

Apache Maven is a de facto standard build system for Java projects. […] The project builds should produce standard Maven artifacts […] and be as simple to execute as running mvn clean install […].

Wie man sich nach der Beschreibung der technologischen Basis für das TCK bereits denken kann, setzten nicht alle Projekte auf moderne Buildsysteme. Besonders unter den etwas älteren Spezifikationen sind durchaus noch Apache Ant und in der Versionskontrolle gespeicherte Abhängigkeiten in Form von JAR-Dateien zu finden. Auch hier schlägt das Dokument vor, auf eine modernere und vor allem einheitliche Basis zu setzen. Auch der größte Gradle-Fan wird hoffentlich zustimmen, dass der Umstieg von Ant auf Maven ein Schritt in die richtige Richtung ist.

Um den Umgang mit Altlasten geht es ebenfalls im nächsten Abschnitt.

Requiring all components to preserve backwards compatibility increases the maintenance burden in both size and complexity. We should extract old and rarely used technologies to optional modules and leave it up to users if they want to use them.

Dieser Punkt betrifft eine Eigenschaft von Java EE, die je nach Betrachtungsweise als eine Stärke oder auch eine Schwäche gesehen werden kann. Java EE hat schon immer großen Wert auf Abwärtskompatibilität gelegt. Und das zu recht. Denn damit erfüllte Java EE die Anforderungen vieler Unternehmensanwendungen, bei denen die Möglichkeit, Anwendungen auch nach vielen Jahren noch betrieben und weiterentwickeln zu können, eine wesentliche Rolle spielt. Der Nachteil dabei ist sicherlich, dass veraltete Konzepte für eine sehr lange Zeit Bestandteil der Plattform bleiben und diese mit der Zeit immer mehr aufblähen. Die Idee, Teile der Plattform in Module zu zerlegen und teilweise optional zu machen, ist daher sicherlich ein guter Weg. Neue Anwendungen können die Altlasten getrost ignorieren und Legacy-Systeme haben dennoch die Möglichkeit, auf aktuellen Versionen der Plattform betrieben zu werden.

Unsere Interview-Reihe: Jakarta EE im Klartext

In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll.

Ab geht die Reise ins Jakarta-EE-Universum mit unseren Experten!

Modularisierung now!?

Bezüglich einer Modularisierung der Plattform geht der nächste Punkt sogar noch einen deutlichen Schritt weiter:

Think carefully before adding hard dependencies. Components depending on half of the world are heavy and not suitable for microservices development. Use a modular approach that allows users to include only functionality that’s needed in their application, while maintaining platform consistency.

Denkbar wäre also ein komplett modularer Ansatz, bei dem man sich die gerade benötigten Teile der Plattform nach Bedarf selbst zusammenstellen kann. Ein einfacher Microservice würde dann beispielsweise lediglich JAX-RS, CDI, JPA und Bean Validation verwenden und EJB, JMS, JCA und vieles weitere außen vorlassen. Spätestens zu diesem Zeitpunkt würde Jakarta EE vermutlich mit dem altbekannten Konzept der „Profiles“ brechen. Seit Java EE 6 steht Nutzern das „Full Profile“ und das leichtgewichtigere „Web Profile“ zur Auswahl. Was damals bei der Einführung ein richtiger und wichtiger Schritt in Richtung leichtgewichtigerer Laufzeitumgebungen war, würde dann vermutlich durch einen vollen Modularisierungsansatz abgelöst werden können.

So schön Modularisierung auch klingt, ohne einen gemeinsamen stabilen Kern geht es dann doch nicht. Genau das wird im Folgenden noch einmal thematisiert.

Dependency injection and configuration should be included in all projects. It will provide consistency between all Jakarta EE components if they are configured the same way.

Der Plan, CDI zu einem zentralen Bestandteil der Plattform auszubauen, auf dem die anderen Spezifikationen aufbauen können, sollte nicht besonders überraschen. Dieser Trend hat bereits vor Jahren begonnen. So hat JSF beispielsweise das eigene Komponentenmodell zugunsten von CDI bereits vor einiger Zeit aufgeben. Ein ähnlicher Schritt wird für JAX-RS bereits aktiv diskutiert. CDI eignet sich aus vielerlei Gründen sehr gut als zentrales Komponentenmodell. So stehen Konzepte wie Dependency Injection, Interceptoren, Events und vieles Weiteres automatisch in der kompletten Plattform zur Verfügung.

Etwas überraschen dürfte die Nennung von „Configuration“ als zukünftig Basis für die Plattform. Niemand wird bestreiten, dass Konfiguration ein ganz wesentlicher Aspekt für die meisten Anwendungen ist. Allerdings muss man auch zugeben, dass Java EE in diesem Bereich bisher keine nennenswerte Lösung anzubieten hatte. Genau diese Lücke versucht das Configuration API 1.0 (JSR 382) zu schließen. Auch wenn sich dieser JSR noch in einem frühen Stadium befindet, so deutet sich bereits an, dass er ein wesentlicher Kernbestandteil von Jakarta EE werden könnte.

Gegen Ende des Dokumentes wird der Releasezyklus noch einmal thematisiert.

We are recommending one year cadence for the Jakarta EE platform. For components the recommendation is 3+1 yearly cadence, where one major release is synchronized with the Platform release and 3 quarterly minor releases.

Wie bereits erwähnt, war der bisherige Release-Zyklus von Java EE oft Kritik ausgesetzt. Jakarta EE will es hier besser machen. Das Ziel ist es, jedes Jahr ein Release der Plattform zu veröffentlichen, wobei die einzelnen Spezifikationen sogar vier Versionen pro Jahr anstreben könnten. Dieser Plan erinnert etwas an das Release-Train-Konzept der Eclipse IDE, welches sich in der Praxis durchaus bewährt hat. Ich persönlich sehe ein Release der Plattform pro Jahr als große Herausforderung. Vor allem dann, wenn man auch die Stabilität und Konsistenz der Plattform aufrechterhalten will. Besonders, wenn es um eine Standardisierung geht, bei der viele Meinungen auf einen gemeinsamen Nenner gebracht werden müssen, sind Dinge nicht immer so schnell umzusetzen, wie es der Endnutzer gerne hätte. Auf der anderen Seite muss man auch zugeben, dass all dies wahrscheinlich einfach eine Frage des zukünftigen Standarisierungsprozesses ist, der für Jakarta EE dann Anwendung findet.

Insgesamt lässt sich sagen, dass sich das EE4J PMC in Zusammenarbeit mit der Community bereits viele gute Gedanken zur Zukunft von Jakarta EE gemacht hat. Viele Bestrebungen brechen mit altbekannten Schwächen von Java EE und werden sehr positiv von allen Beteiligten aufgenommen. Es herrscht Aufbruchsstimmung in der Community und es gibt viel zu tun.

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

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: