Analyse: Oracle scheint bei Java EE im letzten Moment die Kurve zu kriegen

Endlich ringt sich Oracle dazu durch, Java EE womöglich der Community zu übergeben. Die Freigabe erfolgt sehr, aber nicht zu spät. Rainald Menge-Sonnentag von heise Developer sieht in dem Schritt eine große Chance.

 –  47 Kommentare
Kommentar: Oracle scheint im letzten Moment die Kurve bei Java EE zu kriegen
Anzeige

Nun also doch: Oracle möchte Java EE der Open-Source-Community übergeben, wie Software-Evangelist David Delabassee in einem Blogbeitrag ankündigt. Bisher schienen alle Rufe nach mehr Offenheit im Umgang mit der Enterprise-Variante von Java an Oracle abzuprallen. Die Forderung nach einem offenen Gestaltungsprozess nahm vor allem mit einer Petition der Java EE Guardians im Sommer 2016 Gestalt an. Die Gruppe, der unter anderem mit James Gosling der Urvater von Java angehört, beklagte den schleppenden Fortschritt in der Entwicklung von Java EE unter Oracles Führung.

Außerdem bemängelten die Java EE Guardians, dass Oracle sich zunehmend von offenen Standards zurückziehe und die gemeinsame Entwicklung zugunsten eines unilateralen, proprietären Wegs ignoriere. Die Vorwürfe sind allesamt nicht von der Hand zu weisen. In der Tat haben sich zuletzt auf dem Weg zu Java EE 8 viele JSRs (Java Specification Requests) unnötig in die Länge gezogen. Ob das an mangelndem Interesse Oracles an Java EE oder anderer Motivation liegt, muss Spekulation bleiben.

Anzeige

Eine Analyse von Rainald Menge-Sonnentag

Rainald Menge-Sonnentag ist Redakteur bei heise Developer. Als Jugendlicher programmierte er ZX Spectrum und VC 20 in Basic und Assembler. Später kamen zwar Pascal, C++, Java und C# hinzu, aber heute fehlt ihm leider die Zeit zum Programmieren.

An manchen Stellen war das Großunternehmen dagegen auch in der Vergangenheit bereits für Überraschungen gut. Ein gutes Beispiel dafür ist die MVC-Spezifikation 1.0 (Model View Controller). Ursprünglich war sie als Teil von Java EE 8 vorgesehen, aber Oracle kündigte auf der Java One 2016 an, dass der zugehörige JSR 371 eben nicht in Java EE aufgenommen würde. Das führte anfangs zur Sorge, dass Oracle die Spezifikation komplett einstellen wolle. Stattdessen übergab das Unternehmen sie jedoch im Januar 2017 an die Community, die in Folge bewiesen hat, dass sie durchaus in der Lage ist, die Entwicklung größerer Spezifikationen voranzutreiben.

Einige aktuelle Techniken hat Oracle beharrlich zu ignorieren versucht, obwohl sich das Unternehmen erklärterweise auf die Cloud ausrichtet. Beispiel Microservices: Java EE eignet sich technisch betrachtet durchaus zur Umsetzung der verteilten Dienste. Die wichtigen Funktionen wie REST, asynchrones Messaging und Bean Validation sind vorhanden. Für den praktischen Einsatz reicht das jedoch nicht, da leider keine schlanke Variante der Laufzeitumgebung von Java EE vorgesehen ist und selbst das Web Profile zu viel Ballast an Bord hat.

Vielleicht ist daher neben MVC 1.0 die MicroProfile-Initiative ein gutes Vorbild für den künftigen Open-Source-Prozess bei Enterprise-Java. Die Motivation der Initiatoren war im Sommer 2016 das Fehlen einer schlanken Laufzeitumgebung für Java-EE-Anwendungen. Daher hatten sich einige Unternehmen und Organisationen zusammengeschlossen, um ein schlankes Profil zu definieren und zu standardisieren – ihr Ziel ist die Vermeidung einer weiteren Fragmentierung. Herausgekommen ist eine minimale Basis aus JAX-RS (Java API for RESTful Web Services), JSON-P und CDI (Contexts and Dependency Injection). Das Gespann ist dabei lediglich die Minimalanforderung: Anders als bei Java EE können Entwickler für Container und Anwendungen andere Bibliotheken oder aktuellere Versionen hinzufügen.

Ende 2016 übergaben die Initiatoren, zu denen mit Red Hat, IBM, Payara und Tomitribe die Hersteller verbreiteter Java-Anwendungsserver gehören, die MicroProfile-Verantwortung an die Eclipse Foundation. Im Vergleich zu den Prozessen bei Java EE schreitet die Entwicklung bei MicroProfile mit Siebenmeilenstiefeln voran. Hier mag allerdings durchaus die frische Brise des neuen Projekts und wohl auch das Rebellieren gegen Oracle die Beteiligten motivieren.

Dass es zwischen den offiziellen Java-Hütern und anderen Unternehmen nicht immer gut steht, zeigte sich zuletzt nicht in der Enterprise-, sondern der Standardvariante von Java: Mit einer ersten Ablehnung des für Java 9 zentralen Java Platform Module System (JPMS), das vielen eher unter dem Codenamen Project Jigsaw bekannt sein dürfte, im Rahmen des Public Review Ballot, verzögerten mit Red Hat, Tomitribe und IBM auch einige der an MicroProfile beteiligten Unternehmen die Auslieferung von Java 9.

Das wohl keinem Beteiligten ernsthaft daran gelegen war, Java 9 zu gefährden oder gar zu kippen, zeigt die fast einstimmige Zustimmung im zweiten Anlauf. Die Ablehnung darf man daher eher als Warnschuss oder Stolperstein verstehen. Und es ist durchaus eine Machtdemonstration der großen Firmen.

Selbstredend wird ein völlig offener Community-Prozess solche Streitigkeiten nicht aus der Welt schaffen. An dieser Stelle ließen sich viele zerstrittene Open-Source-Projekte nennen. Übrigens ist auch Oracle in der traurigen Liste mit MySQL vertreten: Aufgrund der Kritik der Community, dass der Datenbankhersteller sich zu sehr auf die Enterprise- und zu wenig die offene Variante kümmere, haben viele Firmen es inzwischen durch den Fork MariaDB ersetzt.

Die große Chance besteht aber in der Gleichberechtigung der Beteiligten. Wenn alle dasselbe Mitspracherecht haben, können sie die Standards nach ihren Wünschen gemeinsam formen und haben gleichzeitig nicht mehr die Gelegenheit, auf Oracle als Schuldigen für alle Versäumnisse zu zeigen. So heißt es auch in Oracles Blog "Wir werden uns an der künftigen Evolution der Java-EE-Technologien beteiligen. Aber wir glauben, dass ein offenerer Prozess, der nicht von einem einzelnen Hersteller als Platform Lead abhängig ist, zu größerer Beteiligung und Innovation motiviert und im besten Interesse der Community ist".

Diese Meinung teilen vielen Entwickler, und die Einschätzung von Seiten Oracles ist mehr als überfällig. Für Java EE 8 kommt die Erkenntnis zu spät, aber noch ist Enterprise-Java durchaus zu retten. Hinsichtlich der vielen Themen, die bei Java EE 8 auf der Strecke blieben, benötigt die weitere Entwicklung von Enterprise-Java dringend mehr Zugkraft. Jetzt müssen nicht nur Oracle, sondern auch die anderen Unternehmen zeigen, dass es ihnen ernst ist mit einem offenen Entwicklungsprozess bei Enterprise-Java. Dann stehen die Chancen gut, dass Java EE 9 mehr Neues zu bieten hat als das kurz vor der Veröffentlichung stehende achte Release.

Siehe dazu auf heise Developer:

(rme)

Anzeige