dark

GlassFish 5.1

Avatar

 #JAVAPRO #GlassFish #JakartaEE #Eclipse

Die Java-EE-Referenz-Implementation Eclipse-GlassFish wurde in Version 5.1 Ende Januar 2019 erstmals von der Eclipse-Foundation veröffentlicht. Diese Version implementiert den Java-EE-8-Standard und soll den Grundstein für eine Folgeversion GlassFish 5.2 auf Basis von Jakarta-EE-8 legen, die wenn alles gut läuft, noch in diesem Jahr erscheinen könnte.

Prozessänderung und Kompatibilität

Wie alle Eclipse-Projekte musste GlassFish und alle Komponenten durch die erforderlichen Lizenz-Prüfungen der Eclipse-Foundation. Das Release-Review an sich war dagegen einfacher, da es sich hier um ein so genanntes Minor-Release handelt, in dem keine signifikanten Änderungen an APIs oder Implementationen enthalten sind. Die neuen Versionen der einzelnen Komponenten wurden zwar auf den neuen Maven-Namensraum jakarta (statt javax) umgestellt, inhaltlich wurden aber zwecks Rückwärtskompatibilität keine wesentlichen Änderungen vorgenommen. Diese beschränken sich auf die Behebung von Bugs, die seit Java-EE-8 gemeldet wurden. Im Sprachgebrauch
des Java-Community-Process wäre das also ein Maintenance-Release, wie es etwa für Java-EE-7 auch veröffentlicht wurde. Die Java-Package-Namen selbst, also beispielsweise javax.servlet oder javax.enterprise blieben dagegen gleich. Und werden für bestehende Elemente auch vorerst nicht geändert, um nicht die Kompatibilität mit all den Anwendungen, die Java-EE-Spezifikationen benutzen, radikal zunichte zu machen. Funktionserweiterungen, insbesondere neue Elemente von Standards wie Jakarta-EE-Servlet sollen dann allerdings bereits in entsprechend neue Packages wie jakarta.servlet wandern.

Alle Bestandteile von GlassFish wurden zur Eclipse-Foundation übertragen, einige wenige Ausnahmen bilden etwa CDI (Context-and-Dependency-Injection) oder Bean-Validation, die vorerst von RedHat im Rahmen der JBoss-Community weiterentwickelt und gepflegt werden. Ob sich das auf Dauer ändert ist schwer absehbar. Vermutlich nicht nach der Umsetzung und Bewilligung der geplanten Übernahme durch IBM. Denn beispielsweise den Java-Batch-Standard hat Spec-Lead-IBM, ähnlich wie Oracle, wie die meisten anderen Java-EE-Teilprojekte, auch der Eclipse-Foundation für Jakarta-EE übergeben. Auch wenn RedHat jene Autonomie versprochen wird, die andere Marken wie Rational oder Lotus über viele Jahre genossen, sind Synergien über Kurz oder Lange unvermeidlich. Und was für Batch funktionierte, könnte auch für CDI oder Bean-Validation folgen.

Wie (Abb. 1) zeigt, hat RedHat bei GlassFish 5.1 selbst nur vergleichsweise wenig Code beigetragen (0,8%). Mehr stammt von Payara Services Limited, der Firma hinter der kommerziellen GlassFish Erweiterung Payara. Die Gruppe Contributor ist ein Sammelsurium aus Committern, die keinem Unternehmen zugeordnet werden konnten, also Individual-Eclipse-Foundation-Mitgliedern, aber auch technischen Usern wie dem Eclipse-Glassfish-Bot, der bei den einzelnen Commits mit 31,3% sogar ganz an der Spitze steht. Den Löwenanteil bei Commits durch Unternehmen hält naturgemäß Oracle mit 48,2%, aber selbst wenn das Contributor-Segment nicht immer eindeutig zugeordnet werden kann, zeigt sich doch ein gewisser Anteil an einzelnen Eclipse-Committern bei diesem Release.

GlassFish-Commits nach Unternehmen innerhalb der letzten drei Monate. (Abb. 1)
GlassFish-Commits nach Unternehmen innerhalb der letzten drei Monate. (Abb. 1)

Alle Bestandteile sind Open-Source, dazu gekommen ist für jene von Oracle die EPL 2.0. Der einzige Bereich, der zwar auch transparenter gemacht wurde, aber für Java-EE-8 noch nicht Open-Source freigegeben wird, sind die Kompatibilitätstests, also die Java-EE-Compatibility-Test-Suite und die TCK-Tests für die enthaltenen Standards und Teilprojekte. Oracle-EE4J-PMC-Mitglied und Spec-Lead der JSON-Standards Dmitry Kornilov hat allerdings in seinem Blog-Post über das GlassFish 5.1 Release auf einen Mirror der Testergebnisse für das Java-EE-8 Full-Profile und das Web-Profile verwiesen, der auf der Eclipse-Website liegt und dort transparent erhalten bleibt, selbst wenn Oracle die Tests und Infrastruktur dafür selbst schon abgebaut hätte.

Für die neue Jakarta-EE-Spezifikation sollen alle TCKs und Compatibility-Test-Suiten nicht nur transparente Ergebnisse liefern, sondern auch selbst Open-Source verfügbar sein. Das gehört neben einigen anderen Aspekten zu den Knackpunkten für Jakarta-EE, die von der Kooperation der Rechtsabteilungen bei Oracle, der Eclipse-Foundation und teils auch anderer größerer Konzerne wie RedHat, IBM und dergleichen abhängen. Ebenso wie dem Exekutivkomitee des Java-Community-Process, wo der Spec-Lead bisher von Oracle geleiteter Projekte und Standards auf die Eclipse-Foundation übergehen soll. Solch juristische Fragen sind häufig zäher als die technische Machbarkeit, weshalb noch kein offizieller Termin für Jakarta-EE-8 oder GlassFish 5.1 genannt werden kann, auch wenn viele auf eine Verfügbarkeit im Laufe dieses Jahres hoffen. Dass Oracle besonders im Januar 2019 die Aktivität am Jakarta-EE-TCK-Projekt gegenüber den Vormonaten etwa verdoppelt hat, bestärkt zusätzlich die Hoffnung, dass auch in dem Bereich die Übergabe der zuvor proprietären TCKs in ein Eclipse-Open-Source-Repository voranschreitet und auch die meisten rechtlichen Prüfungen dazu abgeschlossen sein sollten.

Installation

Auf der Download-Seite der Eclipse-Foundation findet man die beiden Archive für das Full-Java-EE-Profile oder das Web-Profile von GlassFish 5.1. Dass glassfish im Dateinamen des Web-Profile weggelassen wurde und der Name nur web-5.1.0 heißt, mutet seltsam an, aber zumindest auf der Download-Seite stellt es kein großes Problem dar. Das Web-Profile-Archiv ist mit knapp 65 Megabytes ungefähr halb so groß wie das des Full-Profile mit 111 Megabytes. Obwohl in der README-Datei „GlassFish 5.1requires Oracle JDK 8 Update 191“ steht, ist das in mehrfacher Hinsicht verwirrend. Oracle-JDK-8 ist seit Januar 2019 genauso lizenz- bzw. abopflichtig wie andere Versionen, insbesondere jene, die als LTS-Version veröffentlicht wurden (das ist bei Java-8 genau wie bei Java-11 der Fall), was zumindest Firmen in die Bredouille bringen könnte. Obwohl GlassFish als Referenzimplementation in produktiven Anwendungen vielleicht nicht mehr die erste Wahl ist, könnte etwa der Test, ob eine Java-EE-8-Lösung auch in GlassFish 5.1 läuft, doch als produktionsnah und nicht bloße Entwicklertätigkeit interpretiert werden. GlassFish 5.1 läuft auch mit Update-192 oder OpenJDK-8, ist aber inkompatibel mit neueren Java-Versionen wie Java-9, 10 oder darüber. Das geht leider aus dem README-Text nicht wirklich hervor, sondern ist nur vage daraus zu schließen.

Konfiguration

GlassFish hatte schon in früheren Versionen eigene Einstellungen wie den AS_JAVA Pfad für die verwendete Java-Runtime-Umgebung, die nicht mit gängigen Mechanismen wie JAVA_HOME übereinstimmen, bzw. diese ignorieren. Zahlreiche andere Application-Server wie Tomcat oder Wildfly nutzen dagegen JAVA_HOME. Und auch Payara, die kommerzielle GlassFish-Erweiterung von Payara Services Limited nutzt eine Kombination aus Pfad-Angaben und JAVA_HOME, um die gewünschte Java-Version für den Server zu definieren. Es bleibt zu hoffen, dass die eine oder andere kommerzielle Erweiterung und Verbesserung die Payara zu Zeiten des von Oracle kontrollierten Java-Community-Process nicht an die Gemeinschaft zurückgeben konnte oder wollte, nun aber in GlassFish einfließen kann. Da GlassFish 5.1
funktional bewusst unverändert blieb, ist dies wohl frühestens mit einer Folgeversion wie GlassFish 5.2 oder danach realistisch.

In GlassFish 5.1 gibt es zwei Möglichkeiten, die gewünschte Java-Runtime zu nutzen. Entweder man ergänzt in der Script Datei <GLASSFISH_HOME>/glassfish/config/asenv.bat für Windows den AS_JAVA Eintrag (Listing 1). Auf diese Weise können auch Umgebungsvariablen wie JAVA_HOME genutzt werden.

(Listing 1)

set AS_IMQ_LIB=..\..\mq\lib
set AS_IMQ_BIN=..\..\mq\bin
set AS_CONFIG=..\config
set AS_INSTALL=..
set AS_DEF_DOMAINS_PATH=..\domains
set AS_DEF_NODES_PATH=..\nodes
set AS_DERBY_INSTALL=..\..\javadb
set AS_JAVA=%_JAVA_HOME%

Oder man setzt in der Konfigurationsdatei <GLASSFISH_HOME>/glassfish/config/asenv.conf den Eintrag AS_JAVA (Listing 2). Hierbei können lediglich Pfadangaben, absolut oder relativ, genutzt werden. Unter Linux bzw. Unix auch symbolische Links.

(Listing 2)

AS_IMQ_LIB=”../../mq/lib”
AS_IMQ_BIN=”../../mq/bin”
AS_CONFIG=”../config”
AS_INSTALL=”..”
AS_DEF_DOMAINS_PATH=”../domains”
AS_DEF_NODES_PATH=”../nodes”
AS_DERBY_INSTALL=”../../javadb”
AS_JAVA=”C:/Program Files/Java/jdk1.8.0_192″

Unter Windows funktionierte das Eintragen in der <GLASSFISH_HOME>/glassfish/config/asenv.conf Datei übrigens nicht, während es in der <GLASSFISH_HOME>/glassfish/config/asenv.bat Batch-Datei sehr wohl klappte.

GlassFish 5.1 starten

Hat man die notwendigen Anpassungen an der Konfiguration vorgenommen, lässt sich GlassFish 5.1 aus <GLASSFISH_HOME>/glassfish/bin mit Hilfe von asadmin start-domain starten. Die Option –verbose liefert detaillierte Log-Informationen direkt in der Konsole. Andernfalls startet GlassFish „silent“ im Hintergrund und man kann in der Konsole weiterarbeiten.

Die Standard-GlassFish-Domäne ist domain1. Möchte man eine andere oder weitere Domäne starten, so ist der gewünschte Name dieser Domäne beim Start zusätzlich anzugeben. GlassFish nutzt den Port 8080 ähnlich wie Tomcat und zahlreiche andere Java-EE-Application-Server. Der Administration-Server ist standardmäßig auf dem Port 4848 erreichbar. Die Administration-Console (Abb. 2) von GlassFish 5.1 hat sich gegenüber GlassFish 5.0 praktisch nicht verändert.

GlassFish 5.1 Admin-Console. (Abb. 2)
GlassFish 5.1 Admin-Console. (Abb. 2)

Einige Links und Seiten wie About… oder Lizenzhinweise in der Hilfe wurden auf die Eclipse-Public-License (EPL) 2.0 als primäre Lizenz geändert. GNU-General-Public-License, version 2 with the GNU-Classpath-Exception dient dabei als Sekundärlizenz. Ansonsten sind sowohl Erscheinungsbild als auch Inhalt der meisten Seiten, auch der Standard-Webseite gleichgeblieben. Die Verweise auf Oracle sowie die alten GlassFish-Seiten bei GitHub sind zwar nicht falsch, wirken aber etwas veraltet angesichts der Community-basierenden Ausrichtung unter der Eclipse-Foundation. Entweder in einem Service-Release oder spätestens mit der nächsten Version dürften auch hier Bereinigungen und Verbesserungen folgen. Mittels asadmin stop-domain lässt sich GlassFish wieder stoppen. Falls man eine andere oder zusätzliche Domäne gestartet hat, muss deren Name auch angegeben werden, ansonsten wird versucht, die Standard-Domäne domain1 zu stoppen.

Ausblick

„Nach dem Release ist vor dem Release“ gilt in Abwandlung der gängigen Fußball-Weisheit auch für die meisten Software-Projekte. GlassFish hat von java.net-JIRA über das dazwischenliegende Java-EE-GitHub-Repository bis zum jetzigen Stand unter Eclipse-EE4J fast 3.500 offene Issue-Tickets angesammelt. Hier ist also noch sehr viel zu tun, selbst wenn sich ein extrem häufiger Release-Zyklus ergeben sollte. In den Diskussionsforen, Wikis und Issue-Trackern finden sich jede Menge mehr oder weniger konstruktiver Vorschläge. Es entsteht der Eindruck als würden einige progressivere Mitglieder der Gemeinschaft Oracle und andere Anbieter am liebsten enteignen wollen. Da die jetzt fünfzehnjährige Eclipse-Foundation zwar herstellerunabhängig ist, die Existenzgrundlage aber auf kommerziellen Mitgliedern und deren Beiträge in Form von Code, Content, Mitgliedsbeiträgen oder Spenden basieren und auch eine Steuerung der Intellectual-Property seit jeher im Interesse der Mitglieder und Nutzer hoch gehalten wird, sind solche Ambitionen oder Protestbewegungen doch eher eine Ausnahme.

Dass es in einer Microservice-, Cloud-Native- oder Serverless-Epoche mehr und wohl etwas feiner geschnittene Profile für Jakarta-EE geben soll, daran zweifelt praktisch keiner mehr. Auch wenn der Weg zu dieser Erkenntnis relativ lange war, die ersten Vorschläge kamen von Mitgliedern der Java-EE-Umbrella-Expertengruppen bereits ab Java-EE-6. Doch die weniger flexiblen Wasserfall-Planungen aus dieser Zeit und auch die eher starren Strukturen bei Sun und später bei Oracle machten es dem Java-Community-Process deutlich schwieriger. Wie viele Profile, Module oder andere Mittel es geben soll, um die Größe und Komplexität der Jakarta-EE-Plattform zu verringern, das ist
einer der Entscheidungsprozesse für das Jakarta-EE-Specification-Committee und andere Jakarta-EE-Arbeitsgruppen.

Initiativen wie das Eclipse-MicroProfile-Projekt, welches in ähnlicher Art und Weise wie die Frameworks Spring oder Dropwizard versucht, sich die Rosinen aus Java-EE herauszupicken und mit anderen Technologien oder Architektur-Entwurfsmustern für Microservices nützlich zu verknüpfen, bieten hier bei der Eclipse-Foundation ebenfalls so manche Inspiration. Einige dieser Muster oder Feature bzw. Fragmente könnten auch in Jakarta-EE gut geeignet sein für eine formellere Standardisierung. Manche erhoffen sich auch von MicroProfile, dass es sich zu einer Art Sandbox und Inkubator für neue Ideen in der Cloud und im Enterprise-Umfeld entwickelt, wovon Jakarta-EE und die damit kompatiblen Produkte und Projekte profitieren würden. Andere sehen in MicroProfile eher ein Marketing-Werkzeug. Der evolutionäre Ansatz nach dem sich Projekte in der Eclipse-Foundation seit mehr als eineinhalb Jahrzehnten entwickeln, sollte letztlich dafür sorgen, dass sowohl Jakarta-EE und auch damit verwandte Projekte und Initiativen die nötigen Synergien finden, die Gemeinsamkeiten zu nutzen und gleichzeitig genug Raum lassen, einige Dinge auch individueller handhaben zu können.

Fazit:

GlassFish 5.1 demonstriert, dass die Übertragung der Java-EE-Community und Code-Basis zur Eclipse-Foundation unter dem EE4J-Dachprojekt inzwischen gelungen ist. Ein wenig hinter der Zeit als erhofft, aus Q3/2018 oder Q4/2018 wurde Q1/2019, was jedoch im Vergleich zu früher üblichen Verzögerungen keine allzu große Verspätung bedeutet. Verlässliche Release-Zyklen die man aus anderen Eclipse Projekten kennt, insbesondere dem Simultaneous-Release der wichtigsten IDE-Projekte, scheinen also auch für Jakarta-EE und GlassFish realistisch. Wie häufig es neue GlassFish-Releases geben wird, wird sich noch zeigen. Alle 13 Wochen wie bei der IDE-Plattform
klingt selbst für eine Specification-Implementation (eine Reference-Implementation wie im JCP bei Jakarta-EE gibt es nicht mehr) etwas zu ambitioniert. Für die gesamte Jakarta-EE-Plattform-Spezifikation dürften wenige Wochen sicherlich keinen ernsthaften Versionszyklus darstellen, auch wenn einige Anbieter wie RedHat mit Wildfly zuletzt praktisch einmal pro Quartal ein Major-Update herausgebracht haben. Hierbei steht wohl eher der Marketingeffekt im Vordergrund.

Egal ob kompatible Implementationen wie GlassFish, Payara, Wildfly oder andere mehrmals pro Jahr neue Versionen veröffentlichen, der eigentliche Jakarta-EE-Standard wird sich vermutlich eher im Jahres-Intervall von 8 auf 9 und darüber hinaus ändern. Zwei oder gar drei signifikante Release-Zyklen scheinen sogar für die ambitioniertesten Anbieter zu viel. Ganz zu schweigen von Endanwendern, die bei Jakarta-EE bzw. Java-EE immer noch überwiegend große Unternehmen sind – bei denen auch Trends wie DevOps, Cloud-Native, Docker oder Virtualisierung die häufig hochkomplexen Systemlandschaften keineswegs von einem Tag auf den anderen über den Haufen werfen können – und wo sicherheits- oder finanzkritischen Lösungen zumindest einige Jahre auf demselben Fundament stabil funktionieren müssen.

Die Liste der in Jakarta-EE-aktiven oder zumindest daran interessierten Unternehmen ist ungefähr so lang wie jene der Mitglieder in den Java-EE-5- oder Java-EE-6-Expertengruppen. Von Branchenriesen wie Oracle, IBM, Fujitsu, Microsoft oder SAP über Newcomer wie Payara oder Tomitribe. Und auch Anbieter teils konkurrierender Systeme wie Lightbend, Liferay, Pivotal oder Vaadin haben ihr Interesse auf der Jakarta-EE-Webseite bekundet.

Werner Keil

Werner Keil ist Cloud-Architekt, API-Designer, Java und Microservice-Berater im Finanzbereich. Nach vergleichbarer Tätigkeit für Banken, Versicherungen und Unternehmen im Bereich Reise, Logistik, Print und Automotive/Embedded, sowie als Agile-Coach,
Java-Embedded und Eclipse-RCP-Experte bei einem Anbieter von Embedded und Realtime Systemen.

Total
0
Shares
Previous Post
JAVAPRO - Deep-Dive into Annotations

Deep-Dive into Annotations – Teil 2

Next Post

5 Aspekte über reaktive Programmierung in Java

Related Posts