Die Community diskutiert: Lukas Eder, Mike Croft

Java-EE-Debatte: „Java EE ist voller schlechter Standards“ [Lukas Eder kommentiert]

Redaktion JAXenter

(c) Shutterstock / astudio

Die Diskussionen um Java EE gehen weiter. Unsere Interview-Reihe zu den Java EE Guardians hat mittlerweile Wellen geschlagen und u.a. eine interessante Diskussion auf Reddit ausgelöst. Wir setzen die Debatte hier fort und laden jeden ein, sich ebenfalls daran zu beteiligen.

In unserer ersten Runde kamen Lukas Eder, Geschäftsführer der Data Geekery GmbH und Erfinder der Datenbank-Bibliothek jOOQ, und Mike Croft, Java Middleware Consultant bei Payara, zu Wort. In Runde 2 reagiert Lukas Eder auf Crofts Kommentar und erklärt nochmals seinen Standpunkt, dass es sich bei Java EE nicht wirklich um einen klassischen Industrie-Standard handelt.

Runde 2 – Lukas Eder: „Java EE ist voller schlechter Standards“

JAXenter: In der ersten Runde unserer Debatte hat Mike Croft gesagt, der JCP umfasse mehr als nur Oracle. Wie siehst du das?

lukas eder java championLukas Eder: Genau so sollte es eigentlich sein, aber aus historischen Gründen ist es nicht so und wird wahrscheinlich auch nie so sein. Oracle ist weitgehend der JCP, sowohl aus legaler als auch aus operativer Perspektive.

Allerdings können Payara und die Anderen, die ihre Kräfte für die MicroProfile-Initiative gebündelt haben, ihr eigenes Komitee gründen. Dieses könnte wirklich offen sein und von einer Foundation statt von einem Einzelunternehmen geleitet werden. Auch da gäbe es natürlich politische Entscheidungen, dennoch glaube ich, dass dieser Schritt einen Fortschritt bedeuten würde, da die legalen Hürden sich wahrscheinlich reduzieren würden.

JAXenter: Glaubst du, dass die MicroProfile-Initiative eine Reaktion von Oracle provozieren wird?

LukasEder: Was ich nicht glaube, ist, dass die Unterstützer von MicroProfile noch mehr Öl ins Feuer gießen wollen. Darum laden sie Oracle offen zur Mitarbeit ein. Meiner Ansicht nach besteht die Strategie allerdings darin, mit Innovationen nach vorne zu preschen und nicht auf Oracle zu warten. Wichtiger ist aber noch, zu Spring aufzuschließen, da Spring Boot den Microservice-Hype aktuell vollkommen dominiert. Sollte sich Oracle dazu entscheiden, Teil von MicroProfile zu werden: gut, warum nicht. So wie ich das sehe, wäre das allerdings eher eine Überraschung.

JAXenter: Mike erwähnte, dass Standards „unglaublich wichtig in der Technologie-Welt [sind], um Fragmentation zu vermeiden.“ Du hast gesagt, es gebe keinen Java EE-Standard. Warum unterscheiden sich eure Ansichten so frappierend?

Lukas Eder: Natürlich sagt Mike das. Er könnte nicht bei Payara arbeiten und nicht dieser Meinung sein :).

Ich widerspreche Mike auch nicht komplett. Wenn ich sage, dass Java EE kein „Standard“ ist, meine ich folgendes: Es gibt gute, „offensichtliche“ Standards, und es gibt weniger gute, weniger „offensichtliche“ Standards.

Ein guter Standard zeichnet sich dadurch aus, Fragmentation dort abzubauen, wo sie ohne irgendeinen Nutzen Reibungen, Mehraufwände und Bürokratie im Markt erzeugt. Einige Beispiele für gute Standards sind:

  • die elektrische Spannung
  • elektrische Steckdosen (Ich hoffe immer noch, dass es irgendwann einen weltweiten Standard gibt anstelle von dutzenden, aber immerhin nutzt die EU weitestgehend einen einheitlichen.)
  • USB
  • die Breite von Schienen
  • die Papierformate DIN A4, A5 usw.
  • JDBC
  • JMS

Diese Standards vereinfachen allen das Leben, indem sie das Geschäft derjenigen zerstören, die abweichende, firmeneigene Lösungen verkaufen wollen. Z.B. impliziert DIN A4 eine Papiergröße von 297 mal 210mm. Die Hersteller von Druckern, Kopierern, von Software, die Dokumente verarbeitet, sowie von Papier, Briefumschlägen, Heftern, Aktenkoffern usw. können gemeinsam „den Standard“ unterstützen, und die Verbraucher müssen sich nicht eine Aktentasche für die JAXenter-Veröffentlichungen und eine andere für andere Dokumente besorgen.

Bei JDBC handelt es sich um einen außergewöhnlich guten Software-Standard. Er macht es überflüssig, Kenntnis von den händlerspezifischen APIs und Netzwerkprotokollen zu haben, um weitgehend auf RDBMS zugreifen zu können (obwohl es auch mit anderen Data Stores funktioniert).

Es gibt einige gute Java-EE-Standards, wie etwa JMS, Servlets, JavaMail und andere. Meistens handelt es sich um solche, die Protokollabstraktionen definieren, oder Dinge, die zu langweilig sind, um sie ein zweites Mal in anderer Weise zu implementieren (JAX-B, JavaMail).

Ein schlechter Standard ist hingegen ein „Standard“, der Innovationen verhindert, indem er zusätzliche Komplexität in eine sehr differenzierte Umwelt einführt, wo verschiedene Meinungen gerade gut für den Markt sind, da unterschiedliche Ansichten hinsichtlich ihrer Wertigkeit für den Konsumenten stark variieren können. Es gibt eine Vielzahl von Business-Standards, wie etwa ISO 9001 fürs Qualitätsmanagement oder den ISO 29119-Software-Testing-Standard, die im Wesentlichen Spezifikationen darstellen, mit denen Unternehmen ihre Kunden beeindrucken wollen. Sie besitzen aber keine konkrete Bedeutung, da es viel zu schwierig ist, von einer einfachen ja/nein-Option abzuleiten, was diese im Kontext eines konkreten Unternehmens wirklich bedeutet.

Java EE ist voller solcher schlechten „Standards“, beispielsweise EJB, MVC, JPA, JSF, CDI, Bean Validation, Batch und so weiter. All diese Dinge haben in einem Standard nichts zu suchen, da sie

  • komplex sind,
  • oftmals eine schlechte Default-Option sind,
  • oftmals nicht die einzige Option, insbesondere nicht der „De-facto-Standard“ (z.B. Bean Validation, Batch) sind,
  • und sehr eigensinnig in Hinblick auf Architektur und Design sind, was den Lösungsraum für die Verbraucher erheblich einschränkt.

Man nehme als Beispiel JSF. Es ist eine serverseitige UI-Komponenten-API-Spezifkation. Doch wie viele Komponenten-APIs haben wir schon? AWT, Swing, JavaFX, GWT, Vaadin, Wicket und viele weitere weniger bekannte. In diesem Fall ist JSF nur eine unter vielen API-Spezifikationen. Klar, es ist eine der aktuell populärsten, aber nur weil es von der „Marke“ Java EE profitiert.

Bei JPA liegt die Sache anders. Diese Schnittstelle löst dutzende Probleme, was eine äußerst schlechte Eigenschaft ist für ein „Standard-API“ ist. Es kümmert sich um:

  • Mapping (das ist der beste Teil)
  • Querying (auf mehrere, widersprüchliche Arten: Mapping, Utility-Finder-Methoden, JPQL, criteria API, Fetch Graphs, native Anfragen, Query-Annotationen, usw. Hält man sich vor Augen, wie viel leistungsfähiger SQL ist, ist keine der Lösungen wirklich zufriedenstellend.)
  • Native SQL (Der Stored-Procedure-Support zeigt meiner Meinung nach nur, wie verzweifelt man versucht, mit den Erfordernissen der echten Welt mitzuhalten, indem man ein Feature in das API zwängt, welches überhaupt nicht für Stored Procedures designed wurde.)
  • Transaktionen (Warum? Es gibt doch schon JTA…)
  • Locking
  • Caching

Eigentlich sollte dieses heterogene Monster in zehn verschiedene APIs aufgeteilt werden. Aber bitte nicht falsch verstehen: Für eine „Implementierung“ wie Hibernate ergibt es durchaus Sinn, diese ganzen Features „Out of the box“ anzubieten. Aber Spezifikationen sollten das nicht tun. Dabei kommt kein guter Standard raus.

Um auf deine Frage zurückzukommen: Wie ich bereits in meinen früheren Antworten erwähnt hatte, liebt die Industrie Garantien, dass bestimmte Dinge auf jeden Fall zusammen funktionieren. Es ist gut zu wissen, dass JDBC funktioniert, dass jOOQ oder Hibernate auf der Basis von JDBC funktionieren und dass keines dieser APIs in der Zukunft kaputt gehen wird. JDBC ist ein Standard. jOOQ und Hibernate sind keine, sondern komplexe Tools, die vom Standard profitieren. Sie treiben Innovationen voran, sie fügen Dinge hinzu und lehnen andere ab oder entfernen sie. Sie sollten deshalb auch keine Standards sein, da sonst ihre komplexe Innovation einfach aufhören würde.

Ich hoffe, dass die MicroProfile-Initiative einen neuen, frischen Blick auf Standardisierungen in Java werfen wird und den „Standard Feature Creep“ verhindert, den es ab J2EE in der Java Enterprise Edition gegeben hat. Mark Littles Kommentar zu diesem Thema scheint genau in diese Richtung zu gehen.



Originalartikel vom 1.7.2016

Runde 1: „Meiner Meinung nach gibt es keinen Java-EE-Standard“

Java-EE-Debatte #1: Lukas Eder

JAXenter: Hallo Lukas! Wenn du dir die aktuelle Situation um Java EE anschaust – glaubst du, wir brauchen eine Gruppe wie die Java EE Guardians?

lukas eder java championLukas Eder: Das ist eine sehr interessante und offene Frage. Und es gibt verschiedene Blickwinkel (natürlich allesamt subjektiv), von denen aus wir sie betrachten können. Zuallererst:

Brauchen wir Java EE eigentlich?

Der „Java-EE-Markt“ ist groß. Viele Unternehmen (nennen wir sie mal „Unternehmen“) wollen „standardisierte“ Software entwickeln, und viele Anbieter von Software-Infrastruktur (nennen wir sie „Anbieter“) wollen ein Stück von diesem Kuchen, indem sie diesen Unternehmen „standardisierte“ Softwareplattformen (und/oder Services für diese Plattformen) verkaufen.

Diese Unternehmen wollen mit möglichst geringer kognitiver Reibung von einem Projekt zum nächsten springen können, und zu viele technische Auswahlmöglichkeiten sind diesem Zweck nicht sehr förderlich. Die Unternehmen bezahlen die Softwareanbieter also für die Garantie, diese Reibungen zu vermeiden. Viele Unternehmen bekommen von den Anbietern sogar einen „Freifahrtschein“, da viele Softwareplattformen kostenlos und Open Source angeboten werden.

In der Vergangenheit haben Java-EE-Evangelisten gerne ein von Standards verzerrtes Bild gezeichnet, in dem der UI-Framework-Markt (häufig ihr Lieblingsbeispiel) größtenteils zwischen Java EE JSF und Spring MVC aufgeteilt wurde. Doch hier greift das alte Sprichwort: „Traue keiner Statistik, die du nicht selbst gefälscht hast!“ Wenn man sich „den Markt“ einmal aus einem anderen Blickwinkel ansieht, stößt man schnell auf AngularJS, das die Szene vermutlich viel mehr beherrscht als JSF und MVC zusammengenommen.

Früher gab es Struts und davor JSP (meiner Meinung nach noch immer die beste Java-Web-UI-Technologie), und vor Java EE (und auch vor J2EE) wiederum andere Technologien, genauso wie es in der Zukunft ebenfalls wieder neue Technologien geben wird. Und wir sprechen hier nur über UI-Frameworks. Es ist demnach klar, dass es selbst im Bereich der sogenannten „Standards“ viele Alternativen gibt, was wiederum wenig überraschend ist, bedenkt man XKCD 927. Meiner Meinung nach gibt es daher keinen Java EE Standard. Java EE ist nur eine empfohlene Menge an Bibliotheken, von denen durch das Java-EE-Zertifikat garantiert wird, dass sie zusammen arbeiten können.

Eine Alternative zu den „Java-EE-Standards“ ist Spring.

Die Antwort, ob wir Java EE überhaupt brauchen, lautet also: „Ja“. Allerdings nur unter der Voraussetzung, dass für einen Nutzer der API die gerade beschriebene Zertifizierung die höchste Priorität hat. Eine Alternative zu den „Java-EE-Standards“ ist Spring, wo Innovationen und neue Features ohne viele formale Prozesse von einem einzigen Anbieter (Pivotal) beigesteuert werden. Dennoch bietet Spring den meisten Kunden den exakt gleichen Mehrwert wie Java EE, nämlich: „Es funktioniert einfach.“ Der Unterschied ist der folgende: Es gibt bei Spring keine Zertifizierung, aber stattdessen das Vertrauen in den Anbieter, das sich auf die vielen Jahre ausgezeichneter Auslieferung von Features stützt. Außerdem gibt es bei Spring keine Konkurrenz bezüglich der Implementierung, da viele APIs proprietär Open Source sind.

Wer natürlich selbst anständige Integrationstests entwickeln kann, für den gibt es eine dritte Alternative zu Java EE und Spring. Dann braucht man beide nicht. Man kann eine beliebige Menge an Drittanbieter-Bibliotheken nutzen, solange man den einzelnen Anbietern vertraut, dass sie das „Richtige“ tun“ (was ohnehin meist der Fall ist, egal ob man nun Java EE oder Spring verwendet). Wenn man beispielsweise jOOQ (oder Hinternate) nutzt, kann diese Bibliothek in einer Standalone-, einer Spring- oder in einer Java-EE-Anwendung gleichermaßen zum Einsatz kommen.

Nun zurück zur eigentlichen Frage:

Brauchen wir eine Gruppe wie die Java EE Guardians?

Wenn es sich bei Java EE wirklich um einen offenen Standard (wie HTML oder zu einem gewissen Grad SQL) handeln würde, dann wären wir nicht in der Situation, in der wir uns gerade befinden. Oracle wäre nur ein Stakeholder unter vielen in einem großen Konsortium, und es wäre ihre eigene Entscheidung, sich aus dem Konsortium zurückzuziehen oder nicht, ohne dem Konsortium als solches zu schaden.

In der Art und Weise, wie der JCP allerdings organisiert ist, diktiert Oracle größtenteils, was im „Standard“ passiert. Beispielsweise sind die TCKs für die meisten Bereiche von Java EE nicht offen, geschweige denn frei verfügbar, sondern verlangen die Zustimmung zu sehr restriktiven Vertragsbestimmungen.

Nun scheint es, als hätte Oracle das Interesse an Java EE verloren (obwohl wir das bisher nicht sicher wissen), und dabei hat Oracle offen gesagt einen ziemlich schlechten PR-Job bezüglich der Kommunikation ihrer Strategie gemacht. Aktuell herrscht deshalb eine große Unsicherheit in der Branche vor, was die Zukunft von Java EE anbelangt. Da Oracle die rechtlichen Aspekte von Java EE fest im Griff hat, kann es keinen Fork oder keinen wirklich offenen Standard ohne Oracles Zustimmung geben. Sollte Oracle also „heimlich“ den Tod von Java EE wollen, dann wird es genau dazu kommen.

So, wie der JCP organisiert ist, diktiert Oracle größtenteils, was im „Standard“ passiert.

Ich persönlich glaube nicht, dass die Java EE Guardians viel an der Situation ändern können. Sicher ist es einen Versuch wert. Die Guardians haben alle ein großes persönliches Interesse an Java EE, da ihre berufliche Karriere davon abhängt. Allerdings gibt es wie gesagt auch nicht-zertifizierte Alternativen wie Spring oder beliebige Drittanbieter-Bibliothekssammlungen, die denselben Zweck wie Java EE erfüllen. Eventuell wäre es der beste Weg, von Grund auf ein neues „Spring“ zu entwickeln, das von einem wirklich offenen Standard-Konsortium geleitet würde, von sämtlichen rechtlichen Verbindungen zu Java EE befreit wäre und mit oder ohne Oracle funktionierte. Nennen wir das Projekt … „Summer“. (Wie es scheint, hat die Community mit dem Projekt „MicroProfile“ eine Initiative gestartet, die genau diesen Zweck erfüllt).

JAXenter: Was glaubst du, wie könnte es jetzt weiter gehen?

Lukas Eder: Erst kürzlich gab es auf Reddits /r/java-Kanal eine interessante Diskussion. Dabei erwähnte der User thesystemx, der dieses Thema regelmäßig kommentiert:

At last Devoxx I spoke to several spec leads and people from Oracle, and they told me (off the record) that the direct licensing income alone is enough to run Java EE, and that excludes the tag on sales for related products.

Und mein erster Gedanke war:

The direct licensing income of a single Exadata installation is probably enough to run Java EE as well, so perhaps this is an order of magnitude thing (i.e. a “what’s this boring, irrelevant stuff over there stop wasting my time thing”)

Wir als Community können also nur darüber spekulieren, was zurzeit passiert. Ich glaube, dass das Geschäft für Oracle schlicht nicht interessant genug ist. Und das gilt auch für die Community, weil sie nicht Oracles Community ist. Es ist die Community von Red Hat, Pivotal, IBM und von allen anderen. Oracle hat von Sun eine ziemlich schwierige Altlast geerbt. Jonathan Schwartz (der ehemalige Sun CEO) bezeugte vor Gericht im Oracle vs. Google-Fall, dass Java „frei“ war (siehe die Berichterstattung über das Gerichtsverfahren auf ArsTechnica). Um aus dem Artikel zu zitieren:

The strategy was, we agree on these open APIs, then we compete on implementations.

Genau das ist es, was ein offener Standard tut, und es war sicherlich Suns Absicht, Java EE als (beinahe) offenen Standard zu „verkaufen“ (genau wie Java SE, welches Gegenstand der Gerichtsverhandlung war). Aber vielleicht hat sich nach all diesen Jahren und etwas ordentlicher Mathematik einfach herausgestellt, dass dieser bestimmte (beinahe) offene Standard Konkurrenten weit größere Vorteile bringt als Oracle selbst.

Doch um es noch einmal zu sagen: Bisher fehlt jegliche offizielle Stellungnahme von Oracle, weswegen wir nur raten können. Fakt ist: Wir als Community können Java EE nicht ohne Oracle voran bringen. Oracle CEO Safra Catz machte dies im Oracle-vs-Google-Verfahren sehr deutlich:

[…] And that Android was an unauthorized fork of Java.

Das bedeutet, dass jeder unautorisierte Fork von Java EE das gleiche Schicksal wie Android ereilen wird. Nebenbei gesagt bezweifle ich sehr, dass wir Oracle davon überzeugen können, uns mit mehr „Freibier“ zu versorgen. Die Zukunft von Java EE steht ohne eine Aussage von Oracle derzeit in der Warteschleife.

Java-EE-Debatte #2: Mike Croft

JAXenter: Hallo Mike! Wie interpretierst du die aktuelle Situation um Java EE? Brauchen wir eine Gruppe wie die Java EE Guardians?

Der JCP umfasst mehr als nur Oracle.

Mike CroftMike Croft: Die Arbeiten an Java EE haben sich verlangsamt, sind aber nicht zum Stillstand gekommen. Der JCP umfasst mehr als nur Oracle, obwohl Oracle dort momentan sicherlich der größte Player ist. Der Fokus der Java EE Guardians liegt darauf, eine Reaktion von Oracle zu erhalten, da dies ihrer Meinung nach essentiell für den Erfolg von Java EE ist. Ich stimme dem insofern zu, als eine Reaktion Oracles wichtig für die Zukunft von Java EE ist – ganz gleich, ob die Reaktion darin besteht, die Arbeiten der von Oracle-geführten JSRs wieder aufzunehmen oder sie der Community zu übergeben. Es ist aber auch wichtig daran zu erinnern, dass Java EE nicht nur eine Sache von Oracle ist, und dass es eine riesige Anzahl von Leuten und Unternehmen unterschiedlichster Größe gibt, die ein begründetes Interesse an dessen Zukunft haben. Die Gruppe der Guardians ist nur eine von vielen Anstrengungen, und wie in jedem anderen Community-getriebenen Projekt sind auch hier alle Bemühungen willkommen.

JAXenter: Wie kann man Java EE aus deiner Sicht weiter bringen?

Mike Croft: Java EE verfügt bereits über einen Plan, wie es weiterentwickelt werden kann, und zwar in der Form der Java-EE-8-Spezifikationen. Bisher haben wir noch keine offizielle Antwort von Oracle vernommen, was ihre Pläne für Java EE 8 betrifft. Wir können also nicht sicher sein, ob die fehlende Aktivität andauern wird oder nur zeitlich begrenzt ist, weil mehr Ressourcen in „andere Projekte fließen“, wie es auf den Mailing-Listen zu lesen war. Wir als Community können allerdings nicht still stehen und auf irgendwelche Verlautbarungen warten. Es ist dieses fehlende Wissen, das Red Hat, Payara, Tomitribe, IBM und die LJC, die alle ein signifikantes Interesse an Java EE haben, dazu getrieben haben, das Projekt microprofile.io ins Leben zu rufen, als einen neuen Weg, eine offene Zusammenarbeit zu ermöglichen.

Es handelt sich dabei nicht um eine Initiative, die darauf abzielt, Oracle auszuschließen. Vielmehr geht es darum, die enorme Mächtigkeit der breiten Java Community zu nutzen, um die Bedürfnisse moderner Java-EE-Anwender zu adressieren. Das Ziel besteht darin, in schnellen Iterationen kollaborativ an einem offenen Standard zu arbeiten. Standards sind unglaublich wichtig in der Technologie-Welt, um Fragmentation zu vermeiden. Von diesem Standpunkt aus blicken wir positiv in die Zukunft.

JAXenter: Vielen Dank für diese ersten Statements!

More to come!

Wenn Sie sich an der Diskussion beteiligen möchten, senden Sie einfach eine E-Mail an redaktion@jaxenter.de

Aufmacherbild: Retro microphone (modifiziert) von Shutterstock / Urheberrecht: astudio

Verwandte Themen:

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: