Java-EE-Faktencheck mit Anatole Tresch

Die Java EE Guardians reden Klartext: „Eine Entwicklung von Java EE in der ASF wäre mir schon sympatisch“

Hartmut Schlosser

Anatole Tresch

Die Debatte um die Zukunft von Java EE geht weiter. Wir haben Anatole Tresch, Spezifikationsleiter des JSR 354 (Java Money & Currency) und PPMC Member von Apache Tamaya, nach seiner Interpretation der aktuellen Situation gefragt.

Update: Mit dem offiziellen Launch der Webseite der Java EE Guardians wurde am vergangenen Freitag auch eine Petitionskampagne an Oracle gestartet. In der Petition wird Oracle aufgefordert klarzulegen, wie Oracle die Interessen des Java-, Java-EE- und Server-seitigen Entwickler-Ökosystems wahrzunehmen gedenkt. Die drei Forderungen an Oracle lesen sich wie folgt:

  • Clarify how it intends to preserve the best interests of the Java, Java EE and servers-side computing ecosystems.
  • Commit to delivering Java EE 8 in time with a reasonable feature set that satisfies the needs of the community and the industry.
  • Effectively cooperate with the community and other vendors to either accept contributions or transfer ownership of Java EE 8 work.

Wer die Petition mitunterzeichnet sendet sie automatisch an die Oracle-Prominenz Larry Ellison, Safra Catz, Mark Hurd, Thomas Kurian, Inderjeet Singh und Anil Gaur. Ein Reaktion Oracles auf die Petition ist uns bislang nicht bekannt geworden.

Nun aber zu unserem Interview mit Anatole Tresch, der als Leiter des Java EE  JSR 354 und gleichzeitiges PPMC-Mitglied bei der Apache Foundation einen interessanten Vergleich zwischen JCP und ASF unternimmt.

„Mir fällt es schwer, mir eine blühende Zukunft für Java EE vorzustellen“

JAXenter: Wie würdest du den aktuellen Zustand von Java EE 8 beschreiben?

Ich würde den aktuellen Zustand von Java EE 8 als ernüchternd bezeichnen.​

Anatole Tresch: Ich würde den aktuellen Zustand durchaus als ernüchternd bezeichnen.​ Wenn ich bedenke, wie lange Java EE 8 bereits am Laufen ist und wie wenig Output aktuell wirklich greifbar ist bzw. in welchem Zustand sich gewisse JSRs befinden, so fällt es mir schwer, mir eine blühende Zukunft für Java EE vorzustellen. Kommt noch hinzu, dass sich mit der zunehmenden Automatisierung in der Infrastruktur (Docker-Container​, Orchestrierung, automatisches Failover, Software Defined Networking, verteilte und resiliente Storage-Backends etc) klassische Funktionen des Java-EE-Ökosystems in die Infrasstruktur verschoben haben. Und mit Linux auf Server-Seite und HTTP/REST als Kommunkations-Mechanismen (Anhänger der Microsoft-Servertechnologien mögen mir verzeihen) verliert das „Write Once-Run Everywhere“-Prinzip von Java auch an Bedeutung.

Das mag viele im Java-Umfeld erschrecken, aber am Ende erhoffe ich mir auch positive Effekte, da meiner Meinung nach Java keine Insel sein darf und die Java Community gut beraten ist, sich im Java-EE-Umfeld Gedanken zu machen, wie und in welcher Form sie auf diese Veränderungen und Entwicklungen reagieren will. Obschon für viele Unternehmen Rückwärtskompatibilität und Stabilität der Java EE Platform große Vorteile bringen, sind diese auch viel Ballast.

Fazit: Ich sehe den Zustand von Java EE 8 aktuell ziemlich kritisch, hoffe aber, dass das Momentum in der Community auch dazu führt, neue Wege und Lösungsansätze zu finden, wie wir Java als strategische Komponente in den Unternehmen auch in Zukunft nützen können.

JAXenter: Jetzt hat sich eine Gruppe namens „Java EE Guardians“ gebildet, die sich zum Ziel gesetzt hat, Java EE voran zu bringen. Mit welchen Aktivitäten könnte das geschehen?

Anatole Tresch: Das​ ist eine ziemlich schwierige Frage, auf die ich auch noch keine klare Antwort habe. Ich denke, wir werden v.a. viele Gespräche führen müssen, speziell auch mit den Partnern bei Oracle und anderen aktiven Unternehmen im Java-EE-Umfeld. Einerseits, um die Wichtigkeit und Verbreitung von Java EE für die Unternehmen zu unterstreichen, andererseits aber auch, um Möglichkeiten für funktionierende Business Cases aufzuzeigen und zu demonstrieren, warum es sich lohnt, auch weiterhin in Java EE zu investieren. Eine Öffnung bzw. Verschiebung der Spezifikationshoheit weg vom JCP soll dabei gerne auch angesprochen werden, weil dies meiner Meinung nach wertvolle Impulse für die Innovation geben würde. Die Linux-Foundation und auch die Apache Foundation zeigen deutlich, dass die wirklich komplexen und anspruchsvollen Probleme kaum noch von einem einzigen oder wenigen Unternehmen alleine gestemmt werden können.

JAXenter: Was waren für die dich Beweggründe, dich den Java EE Guardians anzuschließen?

Anatole Tresch: Ich habe mich in den vergangenen Jahren ​viel mit Java-Lösungen im Unternehmensumfeld befasst und auch heute haben viele Unternehmen nach wie vor Java EE als strategische Plattform im Einsatz. Aber die Akzeptanz und Glaubwürdigkeit von Java EE bröckelt. Für Unternehmen ist aber eine stabile Entscheidungsgrundlage für ihre Investitionen sehr wichtig. Eine Abkehr von Java EE zu komplett anderen Technologie-Stacks ist nicht nur strategisch, sondern auch Ressourcen- und Know-How-technisch eine große Herausforderung und nicht von heute auf morgen machbar. Somit wäre es aus meiner Sicht optimal, Java EE wieder zu neuem Schwung zu verhelfen, damit drängende Fragen und Anforderungen angegangen werden.

Ich sehe mich dabei als Enterprise-Architekt, welcher von je her auch über den Zaun geschaut hat und mithelfen möchte, dass Java EE in Zukunft moderner, modularer und flexibler wird. Dabei ist meiner Meinung nach „weniger mehr“. Funktionierende verteilte Architekturen bauen auf wenigen, einheitlichen und einfachen bzw. nachvollziehbaren Mechanismen auf. Java EE geht leider bis dato eher in die andere Richtung.

JAXenter: Denkst du, es wäre von Vorteil, wenn Java EE gänzlich von der Community entwickelt würde? – Also ohne Oracle-Beteiligung, vielleicht sogar außerhalb des JCP?

Der fachliche Austausch ist bei der ASF durchaus vergleichbar mit dem, was ich beim JCP erlebt habe.

Anatole Tresch: Grunds​ätzlich bin ich als aktiver Apache Committer natürlich in dieser Frage etwas vorbelastet. Aber unbestritten eine große Stärke der Apache Foundation ist gerade, dass es nicht möglich ist, dass ein Unternehmen einseitig Einfluss auf Projekte nehmen kann. Die Community und der Konsens sind quasi fix eingebaut. Wenn ich nun den Einfluss von Oracle auf Java EE betrachte, so wäre mir eine Entwicklung von Java EE in der ASF persönlich schon sympatisch.

Auch aus Unternehmenssicht hat die Open Source Community an Akzeptanz in den letzten Jahren deutlich gewonnen und eine breitere Abstützung würde sicher auch einiges an innovativer Energie und Vertrauen zurückgewinnen. Der fachliche Austausch ist auch bei der ASF sehr intensiv und durchaus vergleichbar mit dem, was ich beim JCP erlebt habe. Aber all das wird nur mit der Unterstützung von Oracle gehen, somit bin ich auch gespannt, was sich an der nächsten JavaOne im September tun wird, wo sich wohl alle wichtigen Kollegen treffen werden.

JAXenter: Welche technologischen Weiterentwicklungen sollten in Java EE deiner Meinung nach umgesetzt werden?

Anatole Tresch: Für mich wäre eine Modularisierung ein absolut zentraler Bestandteil. CDI sehe ich dabei mit seiner Flexibilität, Mächtigkeit und dem mit 2.0 angekündigten Support für Java SE als zentralen JSR für ein zukünftiges Java EE. Alle anderen JSRs, also auch EJB sollten dabei auf CDI aufbauen. Das würde auch die unglückliche Trennung von Java SE und EE verringern und durch die Einheitlichkeit des Ansatzes die Komplexität von Java EE in vielen Anwendungsfällen reduzieren.

Damit einhergehend wäre eine Entkopplung und Weiterentwicklung des Transaktionsmodells ​wichtig. Die ​verbreitete Bindung des Transaktionskontextes an den aktuellen Thread ist dabei ​aufzuheben und mit einem flexibleren und zeitgemäßerem Management des Transaktions​- bzw. Ausführungskontextes ​zu ersetzen. ​Somit könnten Transaktionen ​genau dort benützt werden, wo​ diese noch Sinn machen​ und könnten als separaten Concern spezifiziert werden​. Erste Schritte in diese Richtung wurden z.B. mit @Transactional bereits getan, diese gehen mir aber nicht weit genug. Und speziell die EJB-Spezifikation ist mit ihrer Größe, Komplexität und der Verwebung mit dem transaktionalen Kontext meiner Meinung nach alles andere als leichtgewichtig und mit ein Grund für die langen Umsetzungszyklen bei den Vendoren.

Generell würde ich mir durchgängig explizitere, flexible ​und serviceorientiertere Modelle wünschen, damit Applikationen ​möglichst ohne ​externe ​Konfiguration von administrativen Ressourcen ausführbar sind (​so wie es im aktuellen Java EE Security JSR aktuell angedacht wird). Dies machte die Server austauschbar und würde entsprechend auch die Konkurrenz beleben. Auch wäre es wichtig, das Class Loading oder zumindest die Sichtbarkeit gewisser Ressourcen zumindest in den groben Zügen klar ​zu ​definier​en​, ​um die Portabilität von Applikationen ​weiter zu erhöhen. Und ​dann wäre da natürlich noch ein einheitlicher Konfigurationsmechnismus, so wie wir ihn mit Apache Tamaya vorschlagen.

Von den aktuell laufenden JSRs liegen mir nebst dem bereits erwähnten Security JSR, v.a. CDI 2.0 und der Management JSR am Herzen. Gerade bei letzteren sind die Fortschritte aber leider sehr bescheiden.

JAXenter: Vielen Dank für dieses Interview!

200-anatole-treschA​natole Tresch studierte Wirtschaftsinformatik und war anschließend mehrere Jahre lang als Managing Partner und Berater aktiv. ​Die letzten Jahre war ​Anatole als technischer Architekt und Koordinator bei der Credit Suisse​ tätig. Aktuell arbeitet er ​als Principal Consultant für die Trivadis AG, ist Specification Lead des JSR 354 (Java Money & Currency) und PPMC Member von Apache Tamaya. Twitter: @atsticks

 

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: