Es wurde viel Zeit in die Theorie des Umzugs von Java EE zur Eclipse Foundation gesteckt, nun gibt es endlich erste greifbare Ergebnisse des Prozesses zu sehen. Ganze neun Projekte wurden der Community zur obligatorischen Prüfung vorgelegt und sollen alsbald dem Top-Level-Projekt EE4J hinzugefügt werden.
Grizzly, Tyrus, Mojarra und Jersey – hinter diesen Namen verbergen sich nicht Codenamen für Black-Ops-Operationen und auch nicht das neue Produktportfolio von Volkswagen. Stattdessen sind dies Bezeichnungen für vier der neun neuen Eclipse-Projekte, die einen neuen Meilenstein in Bezug auf den Umzug von Java EE in das Top-Level-Projekt EE4J darstellen.
Damit sind, um in der Umzugsmetapher zu verbleiben, gerade einmal die neun ersten Kisten mit Büchern in der neuen Wohnung. Es fehlen natürlich noch etliche solcher Pakete, aber der erste Schritt ist zumindest, wie versprochen noch in diesem Jahr, getan worden. Die Kartons müssen nun noch ausgepackt und die restliche Einrichtung (der neue, überarbeite JCP etwa) geliefert werden. Und natürlich fehlt an der Türklingel noch der endgültige Familienname (siehe hier).
EE4J nimmt langsam Formen an
Eclipse Grizzly
Das erste Projekt, das Mike Milinkovich auf seinem Blog anführt, trägt den Namen Eclipse Grizzly. Dieses besteht aus dem Eclipse Grizzly NIO Framework, mit dem Entwickler die Vorteile des Java NIO APIs nutzen können, etwa die Skalierung von Servern für tausende Nutzer.
Eclipse OpenMG
Eclipse OpenMQ steht für „Open Message Queue und ist eine vollständig nachrichtenorientierte Middleware-Plattform. Sie ist bereits in GlassFish implementiert und bietet qualitativ hochwertiges, für Enterprise geeignetes Messaging.
Eclipse Mojarra
Wie OpenMQ ist auch Eclipse Mojarra bereits teil von GlassFish. Mojarra ist die Referenzimplementierung für die Spezifikation JavaServer Faces (JSR-372). Wer komponentenbasierte Benutzeroberflächen für Web-Anwendungen in Java schreibt, der wird bereits über die Spezifikation JavaServer Faces (JSF) gestolpert sein. JSF ist dabei auch ein MVC Web Framework mit dem es Entwickler leichter haben, Benutzeroberflächen für serverbasierte Anwendungen zu bauen. Dabei wird insbesondere auf wiederverwendbare UI-Komponenten gesetzt.
Eclipse Message Service API for Java
Das Eclipse Message Service API for Java entspricht dem im JSR-914 enthaltenen Java Message Service (JMS) API, einem Java-Message-orientierten Middleware API für das Senden von Nachrichten zwischen zwei oder mehr Clients. Die Implementierung soll unter anderem das Erzeuger-Verbraucher-Problem gelöst werden.
Eclipse Tyrus
Auch Eclipse Tyrus stellt eine Referenzimplementierung dar, in diesem Fall die Open-Source-Variante des Java API for WebSocket (JSR-356). Vereinfacht wird damit, der Name gibt es bereits her, die Entwicklung von WebSocket-Anwendungen. Das WebSocket-Protokoll stellt Nutzern die beidseitige Kommunikation zwischen Server und Remote Host zur Verfügung. Die Vorteile sind unter anderem niedrige Latenzen und ein geringer Kommunikations-Overhead.
Eclipse RESTful Web Services API for Java (JAX-RS)
Das Projekt Eclipse RESTful Web Services API for Java entspricht JAX-RS, also dem Java API for RESTful Web Services. Die Spezifikation für Java-APIs unterstützt Nutzer beim Erstellen von Web Services, die mit dem REST-Architekturmuster übereinstimmen.
Eclipse Jersey
Hitner dem Projekt Eclipse Jersey verbirgt sich ein REST Framework, das unter anderem die JAX-RS-Referenzimplementierung (JSR-339) beinhaltet. Dabei stellt Jersey ein eigenes API zur Verfügung, das as JAX-RS Toolkit um weitere Funktionen und Werkzeuge erweitert. Ziel des Projektes ist es, die Entwicklung von RESTful Web Services und Clients weiter zu erleichtern. Jersey ist dabei durch eine Vielzahl an Erweiterungs-SPIs individuell an die eigenen Bedürfnisse anpassbar. Zukünftig sollen regelmäßige produktionsfertige Referenzimplementierungen mit GlassFish veröffentlicht werden.
Eclipse WebSocket API for Java
Das API, das Java-Entwickler für die Integration von WebSockets in ihre Anwendungen nutzen, nennt sich Java API for WebSocket und ist im JSR-356 definiert. Das API wird sowohl Client- wie auch serverseitig verwendet und ist zukünftig unter dem Namen Eclipse WebSocket API for Java Open Source verfügbar.
Eclipse JSON Processing
Zum Verarbeiten von JSON-Dokumenten (wozu unter anderem Parsing, Erstellung und Umwandlung gehört), bedarf es eines Java-APIs. Dieses wird zukünftig unter durch das Projekt Eclipse JSON Processing (JSON-P) angeboten. Dieses produziert und konsumiert JSON, dem StAX API für XML nicht unähnlich. Es erlaubt zudem das Erstellen von Java-Objektmodellen für JSON unter Verwendung von API-Klassen (wie das DOM API für XML).
Ausblick & Hintergrund
Formell wurden die Projekte, wie es bei Neuankömmlingen im Eclipse-Universum üblich ist, als Proposal erstellt. Nun werden sie geprüft, bevor dann schließlich der Inkubator durchlaufen wird und sie nach neuerlichen Reviews von dort aus in die Maturität entlassen werden. Diese Review-Schleife ist als Development Process bekannt.
Die Projektleitung der neun Projekte teilen sich Bill Shannon, Ed Bratt sowie Dmitry Kornilov (alle Oracle) und Kevin Sutter (IBM). Die beiden Letztgenannten hatten bereits auf der EclipseCon 2017 in Ludwigsburg (JAXenter berichtete) im Namen ihrer Unternehmen betont, dass sie sich um einen gewissenhaften Umzug und die kontinuierliche Weiterentwicklung von Java EE kümmern wollten.
Lesen Sie auch: Java EE 8 ist da! Das sind die wichtigsten Änderungen und Features
Neben den oben genannten Projekten ist auch die Migration der beiden Projekte EclipseLink (JPA) und Eclipse Yasson (JSON-B) in das Top-Level-Projekt EE4J in Bearbeitung.
Weitere Informationen zum aktuellen Stand der Dinge bei den hier genannten APIs und Tools gibt es auf den jeweiligen Proposal-Seiten der einzelnen Projekte.
