Interview mit Jeff Genender

„Ohne Modularität wird Jave EE 8 die Erwartungen nicht erfüllen“

Gabriela Motroc

Jeff Genender

Wo liegt die Zukunft von Java EE? In der Cloud? In den Händen der Java EE Guardians oder denen von MicroProfile? Wir haben mit Jeff Genender, Java EE Champion und Apache Member, über Java EE 8, die aktuellsten Neuigkeiten und die Initiativen gesprochen, die einen großen Einfluss haben könnten – oder auch nicht.

Die Erklärung von Thomas Kurian von Oracle hat gezeigt, dass das Unternehmen große Pläne für Java im Enterprise-Bereich hat. Viele Leute sind aber weiterhin skeptisch was die Strategie betrifft, die Oracle im September auf der JavaOne-Konferenz enthüllen will. Wir haben Jeff Genender, Java Champion und Apache Member, um eine Reaktion auf die jüngsten Neuigkeiten gebeten und ihn nach seiner Meinung zur Zukunft von Java EE 8 gefragt.

JAXenter: Thomas Kurian von Oracle hat gegenüber InfoWorld geäußert, dass Java EE für die Cloud rebootet wird. Was denkst du darüber?

Jeff Genender: Oracle hat sich bislang sehr in Richtung ihrer eigenen Cloud-Plattform bewegt und Ellison (Larry Ellison, Executive Chairman of the Board and CTO von Oracle Anm. d. Red.) will ein Stück davon. Ellison möchte mehr Einnahmen aus der Cloud generieren, und ich glaube, dass Kurians „Reboot“ von Java EE als Chance angesehen wird, um mehr Menschen in Richtung ihrer Cloud-Initiative zu schubsen. Java EE ist dabei die Karotte, die die Leute da hin lockt – beispielsweise zahlende Cloud-Kunden. Auf den JSR-Listen ist allerdings wenig los. Also gehe ich zum jetzigen Zeitpunkt davon aus, dass es sich mehr um Worte und weniger um Taten handelt. Die andere Möglichkeit ist allerdings, dass Oracle das selbst still und heimlich umsetzt. Ich denke, wir werden es abwarten müssen. Vielleicht wird es einen Reboot während der JavaOne geben, wie die Gerüchteküche sagt.

JAXenter: In deinem Blogpost hast du gesagt, dass du von Anfang an knietief in Java EE gesteckt hast. Wie siehst du die Evolution von Java EE?

Jeff Genender: Java EE, so wie es in der J2EE-Zeit war, war ein Weg, um viele verschiedene APIs zusammen zu bringen und zusammen arbeiten zu lassen, sodass man ein Zertifikat bekam. Das war nötig, damit verschiedene APIs koexistieren konnten, was damals Sinn ergab. Es war allerdings auch ein Alles-oder-nichts-Konzept. Darum entstanden daraus auch immer diese monolithischen Container, die alles außer einer Küchenspüle mitgebracht haben. Über Modularität wurde seit Java EE 6 immer gesprochen, und es war klar, dass wir uns in diese Richtung bewegen müssen. Leider hat das nie geklappt. Obwohl wir inzwischen das Profile-Konzept haben, wird Java EE heute noch immer als monolithisch angesehen.

Ich glaube, dass viele Nutzer es leid sind, monolithische Container laufen zu lassen.

Das größte Problem mit Java EE ist, dass große Anbieter wie IBM und Red Hat die Unterstützung alter Technologien und für Legacy-Anwendungen verlangen. Es ist schwer, APIs wegzuschmeißen, weil sie sicher gehen wollen, dass ihre alten Kunden weiterhin unterstützt werden. Sie verstehen nicht, dass Deprecation ein Teil des Fortschritts einer Technologie ist. Wer Kunden hat, die immer noch EJB brauchen, dann unterstütze weiterhin die alten Versionen, aber versuche nicht, eine neue Spezifikation unter Verwendung von Technologien voranzubringen, die nur noch wenige Leute nutzen.

JAXenter: Glaubst du, dass Java EE 8 die Erwartungen der Community erfüllen wird?

Jeff Genender: Nicht, solange es keine echte Modularität gibt. Der Hauptgrund dafür, dass sich Modularität in der JVM nur schwer umsetzen lässt, ist der kaputte tree-basierte Classloader. Ich glaube, dass viele Nutzer es leid sind, monolithische Container laufen zu lassen. Nutzer wollen leichtgewichtige Stacks, vor allem mit Blick auf die Cloud. Wenn man eine 4-GB-Instanz in der Cloud hat, will man definitiv keinen Container laufen lassen, der 3 GB benötigt, vor allem wenn man 95 Prozent der APIs gar nicht verwendet. Echte Modularität lässt Menschen entscheiden und aussuchen, was sie brauchen, und nicht sich alles in Projekt zu ziehen, nur wegen den Verflechtungen eines Tree Classloaders.

JAXenter: Wird die MicroProfile-Initiative immer noch relevant sein, wenn Java EE 8 sich auf Microservices fokussiert?

Jeff Genender: Ehrlich gesagt glaube ich nicht an irgendeines dieser „Profile“. Uns ist wichtig, dass alle diese Technologien zusammenarbeiten, wenn sie zusammen verwendet werden sollen. Ich muss wissen, dass ich Restful Services nutzen und jede HTTP Engine darunter bauen kann. Ich will aber nicht gezwungen werden, Servlets zu integrieren, wenn ich sie nicht verwende. Es könnte ja sein, dass ich ein performanteres API wie Netty oder Mina nutzen möchte, um meinen HTTP- oder HTTP/2-Base-Traffic zu handeln. Ich will nicht mit Servlets zwangsverheiratet werden.

Wenn Java EE 8 die Kurve kriegt, wird MicroProfile wahrscheinlich irrelevant werden.

Die Idee hinter Microservices ist, dass es nur ein neuer fancy Name für SOA ist. Lass Entwickler genau die Technologien auswählen, die sie nutzen wollen, und sei dir dabei sicher, dass auch alles zusammen funktionieren wird. Sobald wir damit anfangen, „Profile“ zusammenzustellen, bauen wir größere Container zusammen, die kein Entwickler haben will. Mein Unternehmen entwickelt schon lange Microservices für viele weltweite Top-2000-Unternehmen; keine zwei Container sehen dabei gleich aus, wenn es um die verwendeten Technologien geht. Jedes Unternehmen, für das wir die Entwicklung übernehmen, hat eine eigene Liste von Anforderungen, und wir integrieren nur das, was wir dann auch verwenden. So sollte es immer sein. Wenn Java EE 8 die Kurve kriegt, wird MicroProfile wahrscheinlich irrelevant werden, weil sie – zumindest bisher – keinen industrieweiten Support bieten.

JAXenter: Wie sieht es mit den Java EE Guardians aus? Hat die Gruppe die Java-EE-Unterstützergruppe fragmentiert?

Jeff Genender: Die Java EE Guardians haben gar nichts fragmentiert. Sie treten eher als politische Organisation auf, um Support für das JSR von Oracle zu bekommen. Die Fragmentierung ist microprofile.io. Ich denke, dass die Leute von MicroProfile eine stärkere Führungsrolle im JSR hätten übernehmen sollen, oder ihre Initiativen zu JCP hätten bringen und ein neues JSR starten sollen, falls Oracle die Kontrolle über das alte nicht aufgeben will.

Ich bin nicht überzeugt davon, dass MicroProfile in irgendeiner Weise erfolgreich sein wird, wenn sie nicht ein paar der üblichen Verdächtigen zum Mitspielen bewegen und sich in den Sandkasten der JSRs setzen, sodass ein echter TCK eine richtige „Zertifizierung“ anstoßen kann, wenn sie in diese Richtung gehen wollen. Microprofile.io scheint irgendwie desorganisiert zu sein, wie man an ihrer Diskussionsgruppe sieht, und es scheint, als gebe es dort einige innere Machtkämpfe… Darum bin ich mir nicht sicher, ob das alles eine Zukunft hat, falls sie keinen richtigen Kapitän für ihr Schiff finden. Von außen betrachtet sieht Microprofile derzeit wie eine Red-Hat-Marketing-Initiative für Swarm aus. Ich fordere Red Hat dazu auf, die Leitung innerhalb des JCP zu übernehmen und dort auf Veränderungen hinzuwirken, oder vorzutreten und die Führung in der Community zu ergreifen.

JAXenter: Du hast gesagt, dass die Java EE Guardians sich auf die Interessen der Community fokussieren sollte. Welche Interessen sind das? Hast du dazu Vorschläge?

Jeff Genender: Bei Java EE ging es immer darum, die Big Players mit ihren Legacy Clients zu bedienen. Die neue Führung von Java EE – wenn es eine gibt – muss meiner Meinung nach mehr die Community in den Fokus stellen und sich um die Bedürfnisse der Mehrheit kümmern, statt nur um die Interessen derjenigen mit dem höchsten Kontostand. Wenn die Java EE Guardians etwas verändern wollen, müssen sie die Community stärker involvieren und die Stimme der Mehrheit laut werden und zum Teil des JSR und der Spezifikation werden lassen. Bis das passiert, haben wir immer noch die Legacy APIs am Hals und das Konzept der Profile wird nie aussterben.

JAXenter: Ist Java EE noch rentabel?

Jeff Genender: Aus der Perspektive der großen Unternehmen, die die App-Server lizensieren und daraus große Support-Verträge generieren, ist Java EE mit Sicherheit rentabel. Ich denke aber auch, dass die Java-EE-Container-Unternehmen wahrscheinlich Migrationen weg von monolithischen App-Servern erleben und somit sinkende Einnahmen aus Lizenzen- und Support-Gebühren verzeichnen dürften. Java EE wird als überholt angesehen, weil es nicht sehr innovativ ist.

Java EE wird als überholt angesehen, weil es nicht sehr innovativ ist.

Meine Gespräche mit einigen meiner Freunde bei Oracle haben genau das gleiche Bild ergeben: Sie sehen, dass Nutzer von den Big Stacks wegmigrieren. Ich schätze, dass das ein zweischneidiges Schwert für Oracle ist. Sie machen noch immer Geld mit WebLogic, sehen aber vermutlich die Cloud als ihr zukünftiges Geschäftsfeld. Darum gehe ich davon aus, dass sie das als Chance sehen, um im Spiel zu bleiben und auszuprobieren, ob sie es mit ihren Cloud-Diensten verzahnen können.

Der JCP hat in den letzten Jahren umfassende Veränderungen durchlaufen, um Einzelpersonen und Unternehmen mehr Möglichkeiten zu eröffnen, sich für JSRs einzusetzen. Gegenwärtig glaube ich nicht, dass Oracle für das nötig ist, was mit Java EE passiert. Wenn Red Hat, IBM und einige der anderen Big Player etwas verändern wollen, können sie die Führung über das Java EE 8 JSR übernehmen, und wenn Oracle nicht mitspielt, einfach ein neues JSR für ein neues Java EE starten. Nichts würde die Endnutzer mehr schockieren, als wenn alle aus dem Java EE JSR aussteigen und der einzige verbliebene „Experte“ Oracle wäre. Es würde einen schnellen Tod sterben. Die Community hat also eine Menge Macht in dieser Hinsicht… Es muss nur jemand vortreten und die Kontrolle übernehmen – und es richtig machen.

Vielen Dank für dieses Interview!

Screen-Shot-2016-08-09-at-9.52.23-AM-1 Jeff Genender is a Java Champion, Apache Member, and Java Open Source consultant specializing in SOA and enterprise service implementation. Jeff has over 23 years of software architecture, team lead, and development experience in multiple industries. He is an active committer and Project Management Committee (PMC) member for Apache Camel, ServiceMix, CXF, Geronimo, a comitter on ActiveMQ, TomEE/OpenEJB, and Mina, and author of several very popular Mojo (Maven plugins). Jeff also serves as a member of the Java Community Process (JCP) expert group for JSR-366 (Java Platform, Enterprise Edition 8 (Java EE 8) Specification).

 

Verwandte Themen:

Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: