Eine strategische Entscheidung und die Konsequenzen

GlassFish-Support: Aufregung im Maschinenraum

Jens Schumann
©Shutterstock.com/Markovka

Anfang November machte Oracle mit einem unerwarteten Blogpost auf sich aufmerksam, der sofort zu hitzigen Diskussionen und Spekulationen führte: Oracle wird definitiv keinen kommerziellen Support für GlassFish 4, also für die Java EE 7 Referenzimplementierung, anbieten. Was bedeutet das für GlassFish und für die Java EE Plattform? Haben die Schwarzmaler recht? Oder handelt es sich nur um einen der vielzitierten Stürme im Wasserglas?

Zugegeben: In der Java EE Community sind Überraschungen mittlerweile eher die Ausnahme als Regel. Längst vorbei sind die Tage, in denen Keynotes oder Veröffentlichungen mit bahnbrechenden Neuigkeiten aufwarten konnten. Im Jahr 2013, also im Jahr vierzehn nach Java-EE-Zeitrechnung, lebt die Java EE Community in einem stabilen und einigermaßen vorhersehbaren Umfeld, sowohl technologisch als auch politisch. Und das aus gutem Grund.

Dennoch haben unerwartete Ereignisse, zu denen beispielsweise die plötzliche Unterscheidung in Java ME, SE und EE, die Abkehr vom alten EJB 2.x Denkmodell und natürlich der Kauf von JBoss durch RedHat (als erster Beweis, dass „Professional Open Source“ ein funktionierendes Geschäftsmodell ist) zählen, durchaus ihren Reiz. Doch gehört die Ankündigung zum GlassFish Support [1] in die gleiche Kategorie?

Glaubt man den öffentlichen Äußerungen der Java und Java EE Protagonisten, so hat Oracle sich mit der Ankündigung in eine Richtung bewegt, die für die eine Gruppe ein totales Desaster darstellt und für Andere wiederum Anlass für Durchhalteparolen ist. Die Aussagen variieren deshalb irgendwo zwischen „Oracle hat GlassFish getötet“ und „Kopf hoch. GlassFish ist Open Source und wird nie sterben“. Was ist nun passiert?

Fakten bitte

Im besagten Blogpost vom November sowie in einem weiteren FAQ-Post zwei Tage später hat Oracle angekündigt, für zukünftige GlassFish-Versionen keinen kommerziellen Support anzubieten. Gemäß der Oracle Lifetime Support Policy wird kommerzieller Support bis 2017 für GlassFish 2.x und 3.x verfügbar bleiben, GlassFish 4.0 hingegen wird keinen Support erhalten.

Oracle empfiehlt deshalb eine Migration zu dem auch von Oracle angebotenen WebLogic Server, für den es als Closed-Source-Alternative natürlich kommerziellen Support gibt und geben wird.

Der Open-Source GlassFish-Server, so wie wir ihn heute kennen, soll weiterhin als Referenzimplementierung der Java EE Plattform dienen, wenn auch aus jetziger Perspektive mit einer nicht ganz optimalen Lizenz und in noch zur klärender Verantwortung der GlassFish-Entwickler-Community.

Und nun?

Aus der Ferne betrachtet sind die unmittelbaren Konsequenzen für Unternehmen, die heute auf GlassFish setzen, natürlich fatal. Ihre Laufzeitumgebung und damit in der Regel umfassendes betriebliches Know-How geht verloren, neben einer technischen Migration von Java EE Anwendungen steht diesen Unternehmen normalerweise auch ein Neuaufbau von Server-Know-How bevor – oft mit Startpunkt null.

Und auch für die Neuentwicklung von Java EE 7 Anwendungen bedeutet die Ankündigung mehr oder minder ein „Zurück auf Los!“ – leider ohne 4.000 DM einzuziehen. Gerade in Europa bzw. Deutschland haben sich – so unsere Erfahrungen – einige Unternehmen in Q3/2013 wegen Java EE 7 für den GlassFish entschieden und wurden von Oracle ziemlich überfahren. Hier scheint der Zeitpunkt der Ankündigung wirklich schlecht gewählt, da Oracle erst Ende 2014 oder später einen Java EE 7 WebLogic anbieten wird. Die Situation wirkt daher ziemlich hoffnungslos.

Allerdings munkelt man – und die Ankündigung bestätigt dieses mehr oder minder indirekt – das die Anzahl der bestehenden Support-Verträge für den GlassFish eher überschaubar ist. Wenn dem so ist, dann gibt es entweder vergleichsweise wenige produktive GlassFish-Installationen, oder aber eine relativ hohe Anzahl an Installationen nimmt bisher keinen kommerziellen Support in Anspruch.

Hier mag man Oracle vorwerfen können, das Potential des GlassFish und die Auswirkungen der Verfügbarkeit von Java EE 7 Servern unterschätzt zu haben. Eine aktive Zerstörung infolge der Ankündigung – wie von einigen formuliert – lässt sich objektiv betrachtet nicht wirklich erkennen. Eher im Gegenteil: Nach der Übernahme von Sun ist es verwunderlich, wie lange Oracle zwei kommerzielle Java EE Server im Portfolio hatte.

Steilvorlage par excellence

Im FAQ Blog-Post behauptet Oracle nun, dass ein Wechsel zu WebLogic nicht nur technologisch machbar sondern auch von den Lizenzkosten erträglich ist. Dieses Argument wird, zusammen mit leicht falschen Hinweisen zum kommerziellen Support anderer Anbieter, als Begründung für eine Migration zu WebLogic aufgeführt.

Doch auch wenn Oracle einen guten Migrationspfad vom GlassFish zum WebLogic Server aufzeigen wird, zeichnet die Reaktion der Java EE Community ein anderes Bild: Statt Oracle zu vertrauen bewerten Betroffene ausgehend von der Liste der verfügbaren Java EE 6 Server die Zukunftssicherheit der Server und die Kosten einer Migration (Transitions-, Lizenz- und Betriebskosten) und treffen auf dieser Basis ihre Entscheidung. Fraglich ist dabei, ob der WebLogic Server, der definitiv ein sehr gutes Produkt ist, mit seinem sehr späten Releasezyklus und betagten Preismodell eine tragende Rolle spielen wird.

Vielmehr scheinen momentan der JBoss Application Server 7 bzw. WildFly sowie TomEE die Nase vorn zu haben, vor allem weil sie heute frei verfügbar sind und kommerzieller Support vorhanden ist. Zu beobachten bleibt lediglich, inwieweit TomEE die Oracle Steilvorlage wirklich nutzen kann, da wesentliche Bestandteile des Servers (OpenWebBeans, OpenJPA) derzeitig nicht den Anschein machen, in naher Zukunft die Java EE 7 Spezifikation zu erfüllen.

Zurück zum J2EE SDK?

Bei allen Unwägbarkeiten bleibt immer noch die Möglichkeit, auf GlassFish ohne kommerziellen Support zu setzen. Im Falle von GlassFish 4.0 dürfte diese Entscheidung noch ohne große Konsequenzen sein. Es ist allerdings zu erwarten, dass Oracle das abgestellte GlassFish Entwicklerteam Zug um Zug verkleinert, sodass die Umsetzungsgeschwindigkeit und Qualität des Servers in jedem Fall leiden dürften.

Die Referenzimplementierung GlassFish könnte sich damit zurück zum Status des früheren J2EE SDK entwickeln: „Play with it, but don’t use in production“.

Engagement kann retten

Insgesamt hat Oracle mit der Support-Ankündigung sicherlich mehr Porzellan zerschlagen als notwendig gewesen wäre. Dennoch ist die Aufregung um den Support-Status unverständlich – sofern man sich der Tatsache bewusst war, dass Oracle schon vor mehr als zehn Jahren eine Transformation von einem Technologieunternehmen hin zu einer sehr erfolgreichen Mergers-and-Acquisitions-Company vollzogen hat. Unrentable Geschäftsbereiche, finanziell oder strategisch, gehören nach diesem Verständnis nicht ins Portfolio und werden eingestellt oder abgestoßen. Damit sollte klar sein, dass Oracle – wie viele andere Unternehmen und im Gegensatz zu Sun – nicht Technologie sondern den Businessnutzen von Technologie bewertet und auf dieser Basis Entscheidungen trifft. Die Konsequenzen sind nicht immer optimal, allerdings hat Sun auch gezeigt, dass technologische Verliebtheit nicht unbedingt zu guten Produkten und damit zu Erfolg führt.

Bleibt zu hoffen, dass die Referenzimplementierung GlassFish auch noch in Zukunft ihrem Namen gerecht wird und nicht zu einer Java EE Implementierung heranwächst, die zwar die einzelnen Spezifikationen umsetzt aber in Summe nicht über die (schlechte) Qualität heutiger GlassFish Beta Releases hinauskommt. Hier ist allerdings auch die Java EE Community gefragt, die – eine passende Lizenzierung des Source-Codes vorausgesetzt – das Schicksal des Servers selbst in der Hand hat. Auch ohne Support-Vertrag können Releases getestet, Bugs gemeldet und Features eingebracht werden.

Für diese Unterstützung müsste Oracle jedoch noch einige Voraussetzungen schaffen (Lizenz, Verantwortung, Source Repository), die Apache Software Foundation und/oder GitHub helfen sicherlich gern.

Leider ist zu erwarten, dass ähnlich wie bei Apache Geronimo, eine breite Unterstützung durch die Community ausbleibt, sodass am Ende die Gewinner WildFly und mittelfristig – mit Java EE 7 Support – WebLogic heißen dürften.

Aufmacherbild: Vector round shapes watercolor seamless ornament. Paints. von Shutterstock / Urheberrecht: Markovka

Geschrieben von
Jens Schumann
Jens Schumann
Jens Schumann, Softwarearchitekt bei dem IT-Beratungs- und Entwicklungsunternehmen open knowledge GmbH sowie freier Autor, beschäftigt sich seit vielen Jahren mit dem Design und der Umsetzung komplexer Lösungen im Enterprise-Computing-Umfeld. Neben den rein theoretischen Ansätzen liegen vor allem die anwendungsbezogenen Aspekte dieses Problemfeldes im Fokus seiner Tätigkeit. Seine praktische Erfahrung sammelte Jens Schumann in diversen großen, internationalen Projekten und gibt sie als Vortragender auf deutschen und amerikanischen Konferenzen sowie durch sein Engagement innerhalb diverser Open-Source-Projekte weiter. Seine Schwerpunkte bilden derzeit vornehmlich die Aspekte des serverseitigen Java, der aktuelle Fokus liegt dabei im Speziellen auf der Umsetzung von verteilten Anwendungen und der Schaffung einer Enterprise-Java-basierenden Mobile-Computing-Infrastruktur.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.