GlassFish: Ein Nekrolog für Oracles Open-Source Anwendungsserver

Inhaltsverzeichnis

Am gestrigen Montag verstarb der Open-Source-Anwendungsserver GlassFish. Denn Oracle hat verkündet, den kommerziellen Support für den Server einzustellen. Das bedeutet, dass beginnend mit der GlassFish Open Source Edition 4, der Referenzimplementierung für Java EE 7, keine zugehörige Version von Oracles kommerziellem GlassFish Server mehr erscheinen wird. Der offizielle Upgrade-Pfad für die Open-Source-Version des GlassFish ist jetzt der WebLogic Server.

Damit ist wahr geworden, was schon lange befürchtet wurde. Bereits Anfang 2010, kurz nach der Sun-Übernahme, gab es Spekulationen und Verwirrungen um die Zukunft des kleinen, aber feinen Servers unter dem großen Dach von Oracle. Es hat fast dreieinhalb Jahre gedauert, bis die damals als düster und unwahr abgetanen Vorahnungen wahr geworden sind. Aber warum eigentlich? Nur weil Oracle offensichtlich nicht genug Geld mit den Lizenzen der kommerziellen Variante verdient hat und diese jetzt einstellt, muss das doch noch lange nicht das Ende des Open-Source-Servers bedeuten? Leider doch – und dafür gibt es Gründe.

Vordringlichstes Argument ist, dass die Teams laut Oracle schon seit längerem zusammengeführt wurden. Das heißt, dass es streng genommen gar kein GlassFish-Team mehr gibt. Das scheint schon seit ein paar Monaten der Fall zu sein. Mit dem Wegfall der Notwendigkeit, eine kommerzielle Version zu erstellen, werden vermutlich etliche bekannte Fehler aus dem 4.0-Release gar nicht mehr beseitigt. Diverse Twitter-Meldungen deuten darauf hin.

Auch ist davon auszugehen, dass sich die Arbeitszeit einzelner Mitarbeiter zwischen GlassFish und WebLogic Server schon lange nicht mehr 50/50 verteilt und sich zunehmend in Richtung WebLogic verschoben hat. Es bleibt also eine Menge Arbeit liegen. Aber seit gestern stört Oracle das nicht mehr. Der GlassFish ist ja nun kein Server mehr, den man auch kommerziell unterstützen muss, sondern nur noch die Referenzimplementierung der Java-EE 7-Spezifikation.

Statt bisherigen nichtfunktionalen Anforderungen seitens der Kunden wie Fehlerfreiheit und Stabilität gibt es nun nur noch eine einzige Anforderung: die fehlerfreie Ausführung des TCK. Dabei ist es sicherlich kein Geheimnis, dass das TCK (Technology Compatibility Kit) weder alle spezifizierten Anforderungen abdeckt noch in irgendeiner Form ein Garant für einen produktionssicheren und stabilen Java-EE-Applikationsserver ist.

Warum brauchen Kunden eigentlich Support?

Die Erfahrung hat gelehrt, dass kein Kunde ernsthafte Anwendungen betreiben kann, ohne für die eingesetzten Produkte Hersteller-Support zu beziehen. Das fängt bei Kleinigkeiten wie der Integration in die vorhandene Infrastruktur an und hört bei produktionskritischen Fehlern auf. Und im Umkehrschluss haben Kunden auch an kommerzielle Versionen von Produkten eine andere Anforderung. Es wird eine gewisse Stabilität und Fehlerfreiheit, ganz allgemein gesprochen Qualität erwartet. Das ist eine symbiotische Beziehung zwischen Open Source und darauf aufbauendem kommerziellen Produkt. Die Kunden zahlen, und das Produkt liefert.

Auch die Open-Source-Varianten profitieren davon nicht unerheblich, da ein breiter Einsatz auch viele Fehler entlarvt sowie nach und nach die Qualität steigert. Das wird es mit dem GlassFish Server jetzt nicht mehr geben. Damit ist er keine echte Alternative mehr.

Aber wie verhält es sich mit dem Upgrade-Pfad zum WebLogic Server? Wer irgendwann einmal versucht hat, eine Java-EE-Anwendung auf mehr als einem Server zum Laufen zu bekommen – und die sich dann auch noch gleich verhalten sollen –, der weiß, was alles dafür nötig ist. Auch wenn sich GlassFish und WebLogic vergleichsweise viele gemeinsame Komponenten teilen, ist immer noch ein erheblicher Anteil Glue Code zwischen ihnen notwendig. Und in diesem Kleber und dem Zusammenspiel der Komponenten stecken auch vielfach die Fehler.

Wer also eine nicht triviale Anwendung auf dem GlassFish am Laufen hat, kann mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, dass diese auf dem WebLogic erst mal nicht funktioniert. Der Grund sind nicht notwendigerweise nur Fehler. Es gibt auch einen nicht unerheblichen Funktionsteil, den die Java-EE-Spezifikationen nicht ausreichend abdecken, beispielsweise Security-Features. Es fällt also Migrationsaufwand an.

Was sind die guten Neuigkeiten?

Die gute Neuigkeit ist, dass sich Oracle dazu durchgerungen hat, die latente Unsicherheit der vergangenen Jahre zu beenden. "Lieber ein Ende mit Schrecken, als ein Schrecken ohne Ende." Genau das ist passiert. Wo die GlassFish- und WebLogic-Teams schon vor längerer Zeit organisatorisch zusammengefasst worden sind, war es jetzt Zeit für den letzten Schritt. Dieser wird den Mitbewerbern helfen. Es verbleiben zwei Open-Source-Server, für die sich kommerzieller Support erwerben lässt: TomEE (mit Support durch Tomitribe) und WildFly (via Red Hat).

Was kann Oracle jetzt noch für die GlassFish-Community tun?

Wenn GlassFish nicht sinnlos gestorben sein soll, muss Oracle noch ein wenig mehr tun, als nur ein kurzes Statement abzugeben. Um den GlassFish weiterhin als Alternative im Markt zu positionieren, muss vordringlichst ein klarer und vor allem abgesicherter Upgrade-Pfad her. Also nicht nur ein Papiertiger, sondern vielmehr ein stabiles, getestetes und etabliertes Szenario mit Anleitungen und Best Practices, in dem die problemlose Nutzung des GlassFish während der Entwicklung und im Übergang zur Produktion mit WebLogic unterstützt wird. Dafür müssten sich Einstellungen an beiden Servern zumindest in einem Kompatibilitätsmodus betreiben lassen, um Änderungen an der Konfiguration von einem zum anderen Server vollständig gleich durchführen zu können.

Wenn GlassFish in irgendeiner Form überleben soll, muss Oracle den Weg zur Beteiligung der Community neu gestalten. Angefangen beim leidvollen Oracle Contributer Agreement (OCA) bis hin zur Lizenz der Sourcen und dem Einsatz eines dedizierten Community-Managers inklusive dem Wechsel hin zu einer Code-Plattform wie GitHub – hier sind viele Dinge denkbar. Bleibt die aktuelle Situation unverändert, wird der GlassFish innerhalb kürzester Zeit nicht mehr einsetzbar sein. (ane)