#JavaEE #EE4J #Eclipse
Die bislang unter dem Namen „Java EE“ bekannte Entwicklungsplattform ist wiederim Aufwind. Nach einer längeren Phase der Ungewissheit, während der sogar das Ende der Plattform befürchtet wurde, erschien im September endlich das neue Release Java EE 8. Die ersten kompatiblen Application Server stehen so langsam in den Startlöchern – höchste Zeit also für einen detaillierten Blick auf die Neuerungen. Ebenfalls im Herbst gab Oracle bekannt, die alleinige Kontrolle über Java EE aufzugeben und an die Eclipse Foundation zu übertragen. Ein Schritt, der allseits für große Zuversicht sorgt, der aber auch viele Änderungen mit sich bringt, unter anderem eine Namensänderung.
Die Fertigstellung einer Java-EE-Spezifikation geht einher mit der Bereitstellung einer Referenz-implementierung in Form eines Application Servers. Im Falle von Java EE 8 handelt es sich dabei um GlassFish 5, der in den Varianten Web-Profile und Full-Platform seit Herbst zum Download bereitsteht und für erste Experimente mit dem neuen Release eingesetzt werden kann. Zusätzlich sind entsprechende Docker-Images verfügbar. Wie gewohnt benötigten die Hersteller der anderen Application-Server im Anschluss einige Zeit, um ihre mit Java EE 8 kompatiblen Releases fertig zu stellen. Inzwischen sind aber große Fortschritte gemacht worden, und die ersten Release Candidates wurden veröffentlicht. Grundsätzlich besteht daneben aber natürlich die Möglichkeit, auch ohne Application-Server einzelne Bestandteile von Java EE 8 einzusetzen. Dies geschieht indem die Implementierungen der jeweiligen APIs einer Anwendung hinzugefügt werden, die beispielsweise in Tomcat oder Jetty betrieben wird. Um etwa die neuen Features von JAX-RS 2.1 nutzen zu können, muss lediglich Jersey 2.26 Bestandteil der Anwendung sein.
Unterstützung für HTTP/2
Java EE 8 führt keine bahnbrechenden neuen Konzepte ein, beinhaltet jedoch eine ganze Reihe sinnvoller Ergänzungen und Modernisierungen, die bislang teils schmerzlich vermisst wurden.
Eine dieser wichtigen Modernisierungen wird von Servlet 4.0 umgesetzt, das nun Unterstützung für HTTP/2 bietet. HTTP/2 wurde 2015 standardisiert und wird mittlerweile von allen gängigen Browsern beherrscht. Hauptziel der neuen Protokollversion sind eine geringere Latenz und eine damit einhergehende Beschleunigung beim Laden von Webseiten. Dies wird durch eine ganze Reihe von Maßnahmen erreicht, wie etwa der Kompression von HTTP Headern oder dem Multiplexing mehrerer Requests über die gleiche TCP-Verbindung. Gleichzeitig ist HTTP/2 vollständig rückwärtskompatibel zu HTTP/1.1: Bekannte Konzepte wie Methoden oder Statuscodes wurden erhalten; Kommunikationspartner wie beispielsweise Browser und Web-Server können sich über ein standardisiertes Verhandlungsprotokoll auf eine Protokollversion verständigen. Da alle diese Veränderungen letztlich die Protokollebene betreffen, sind sie für Anwendungsentwickler überwiegend transparent. Daher fallen die für HTTP/2 relevanten API-Änderungen in Servlet 4.0 sehr gering aus. Die wesentliche Änderung ist ein neuer PushBuilder, mit dessen Hilfe Anwendungen das neue HTTP/2 Server Push verwenden können. Mittels Server-Push kann ein Server zusätzlich zu einer vom Client angeforderten Ressource noch weitere Ressourcen zurücksenden, und zwar schon bevor der Client diese explizit angefordert hat. So könnten etwa bei einer Anforderung von index.html neben dieser Seite selbst gleich noch die verknüpften Stylesheets oder Grafiken an den Client gesendet werden. Es wäre somit nur ein einziger Request notwendig, um all diese Ressourcen zu erhalten.
Neues für die Arbeit mit JSON
Auch hinsichtlich der Unterstützung für JSON bietet Java EE 8 einige wichtige Erweiterungen. So unterstützt JSON-P 1.1 nun JSON Pointer (RFC 6901), JSON Patch (RFC 6902) und JSON
Merge Patch (RFC 7396). Im Zusammenspiel mit der im ebenfalls aktualisierten JAX-RS 2.1 eingeführten serverseitigen Unterstützung für HTTP PATCH lassen sich PATCH-Operationen für REST APIs nun deutlich einfacher implementieren als bisher. Neben diesen Basisfunktionalitäten für die Arbeit mit JSON-Formaten stellt insbesondere auch das neue JSON-B 1.0 (JSON-Binding) eine wichtige Ergänzung der Plattform dar. Dabei handelt es sich in etwa um das Äquivalent von JAXB für die JSON-Welt, also einen standardisierten Mechanismus zur automatischen
Umwandlung zwischen JSON-Strukturen und Java-Objekten.
Hierzu definiert JSON-B eine leicht zu verwendende API, sowie umfangreiche Regeln für ein Default-Mapping, so dass im einfachsten Fall keinerlei Anpassungen an den Modellklassen
notwendig sind. Das Default-Mapping umfasst Konventionen für die Umwandlung der gängigsten Datentypen, von Klassen und Collections, aber auch für die Behandlung von NULL-Werten
oder die Attributreihenfolge.
Für solche Fälle, in denen das Default-Mapping entweder nicht ausreicht oder schlicht von den Anforderungen einer konkreten Anwendung abweicht, können Entwickler entsprechende
Custom-Mappings einsetzen, die beschreiben in welcher Art von den Konventionen des Default-Mappings abzuweichen ist. Dies geschieht typischerweise mithilfe von Annotationen wie @Jsonb
Property (zur Umbenennung von Properties und zur Festlegung der Behandlung von NULL-Werten) oder @JsonbPropertyOrder (Attributreihenfolge). Diese Annotationen können an Attributen,
Properties, Typen und in manchen Fällen sogar Packages angebracht werden. Alternativ dazu können über die JSON-B-API auch so genannte Strategien konfiguriert werden, die ein bestimmtes,
vom Default-Mapping abweichendes Verhalten dann global für alle Modellklassen umsetzen. Für besonders schwierige Fälle können zudem mit Hilfe der generischen Schnittstelle Jsonb Adapter auf einfache Weise auch eigene Umwandlungsregeln implementiert werden. Hierzu sind lediglich die Methoden adaptToJson und adaptFromJson zu implementieren. Dies ist beispielsweise dann notwendig, wenn mehrere Attribute eines Objektes auf nur eine JSON-Property abgebildet werden sollen, oder umgekehrt. Die Einführung einer standardisierten API für das JSON-Binding bedeutet für Entwickler im Wesentlichen, dass künftig die Abhängigkeit auf eine proprietäre Lösung, wie etwa das beliebte Jackson Framework, entfallen kann.
Weiterentwicklung von JAX-RS
Das bereits erwähnte JAX-RS 2.1 bietet neben der Unterstützung für http-PATCH und der engen Integration mit JSON-B zur Umwandlung eingehender und ausgehender Nachrichten noch einige weitere spannende Neuigkeiten. Hier sind insbesondere die Unterstützung von Server-Sent-Events (SSE) und eine neue reaktive Client-API zu nennen. Bei SSE handelt es sich um einen Standard, der bereits 2015 vom W3C verabschiedet wurde und eine Alternative zu den verbreiteten Polling-Szenarien bietet. Beim Einsatz von Polling senden Clients periodische Requests an ein Backend, um den aktuellen Status einer Ressource abzufragen. Vor allem in solchen Fällen, in denen sich dieser Status eher selten ändert, bedeutet dies eine erhebliche Last für die betreffenden Systeme und das Netzwerk, die gleichzeitig überwiegend nutzlos ist. Beim Einsatz von SSE können Clients sich dagegen mit einem einzigen Request für Ereignisse eines bestimmten Typs (Event-Stream) registrieren, also beispielsweise für Änderungen an einer bestimmten Ressource. Im Anschluss an diese Registrierung kann das jeweilige Backend dann im Falle einer tatsächlichen Datenänderung ein entsprechendes Event an den Client senden. Haben sich mehrere Clients für das gleiche Ereignis registriert, kann dessen Versand als Broadcast geschehen. Somit werden nach der initialen Registrierung der Clients nur noch dann Nachrichten über das Netzwerk versendet, wenn tatsächliche Datenänderungen vorliegen. Gegenüber der Polling-Variante ergibt sich somit eine deutliche Reduzierung des Kommunikationsaufkommens. Ein mögliches Einsatzszenario im Zusammenhang mit JAX-RS könnte eine Single-Page-Anwendung
(SPA) sein. Jede Instanz dieser Anwendung registriert sich als SSE-Client bei einem JAX-RS Backend. Sobald das Backend beispielsweise einen PUT- oder PATCH-Request empfängt, welcher bestimmte Ressourcen verändert, werden die einzelnen SPA-Clients mittels eines entsprechenden Events darüber informiert. JAX-RS 2.1 bietet hierfür entsprechende API-Erweiterungen für das Backend, die API für eventuelle JavaScript-Clients wird dagegen vom SSE-Standard selbst definiert. Aber auch in Java implementierte SSE-Clients werden von JAX-RS 2.1 unterstützt. Somit sind auch serverseitige Anwendungen denkbar, die sich als SSE-Clients bei anderen Systemen registrieren.
Eine zweite interessante Erweiterung in JAX-RS 2.1 ist die neue reaktive Client-API. Schon bisher war es möglich, REST-Requests asynchron auszuführen, das heißt den Versand des HTTP Requests in einen separaten Thread auszulagern. Dabei hatten Entwickler die Wahl, ob sie zur Behandlung der Response entweder eine von der API zurückgelieferte Instanz von Future einsetzen wollten, oder ob ein Invocation Callback übergeben wurde. Beide Ansätze haben jedoch ihre Schwächen. Im Falle von Future muss das Resultat irgendwann mittels eines blockierenden
Aufrufs abgeholt werden. Der Einsatz eines Invocation Callback führt dagegen zwar zu nicht-blockierendem Code. Dafür ist die Implementierung mehrerer zusammenhängender Requests jedoch aufwendig und führt zu schlecht wartbarem Code, da in diesem Fall mehrfach verschachtelte Invocation Callbacks zu implementieren sind. In Java SE 8 wurden für genau solche Fälle CompletionStage und CompletableFuture eingeführt. Sie erlauben die einfache Implementierung mehrstufiger Abläufe, deren einzelne Stufen asynchron ausgeführt werden, und die jeweils von den Resultaten der vorherigen Stufen abhängen. Der Einsatz von CompletionStage führt in solchen Fällen zu deutlich besser lesbarem Code, bei dem die implementierte Fachlichkeit klarer erkennbar wird. Die neue reaktive Client-API von JAX-RS 2.1 verwendet nun CompletionStage als Rückgabewert beim asynchronen Versand von REST-Requests. Zudem wurde die API erweiterbar ausgelegt, so dass JAX-RS Implementierungen optional auch andere reaktive Frameworks wie beispielsweise RxJava unterstützen können.
Asynchrone Events für CDI
Auch die beliebte Komponententechnologie CDI wurde für Java EE 8 überarbeitet. Eine wesentliche Neuigkeit besteht darin, dass CDI 2.0 nun auch Java SE unterstützt. Zu diesem Zweck wurde die Spezifikation in die Abschnitte Core-CDI, CDI in Java SE und CDI in Java EE unterteilt. Der erste Abschnitt definiert dabei die zentralen Konzepte wie Qualifiers, Scopes, Alternatives, Stereotypes oder das Programmiermodell, während die anderen beiden Teile die Details beschreiben, welche für die jeweilige Umgebung relevant sind. Für den Einsatz von CDI in Java SE wurden dabei im Wesentlichen das Bootstrapping des CDI-Containers, Scopes, sowie Paketierung und Deployment definiert.
Eine weitere wichtige Neuerung betrifft die CDI-Events. Diese konnten bislang nur synchron abgefeuert werden, und auch die jeweiligen Observer wurden synchron ausgeführt. Dies konnte zu längeren Blockaden führen, zudem war die Ausführungsreihenfolge der Observer nicht definiert. Und schließlich werden im Falle einer auftretenden Exception in einem der Observer alle eigentlich noch folgenden Observer für das jeweilige Event nicht mehr aufgerufen. Mit CDI 2.0 wurde daher nun die Möglichkeit geschaffen, synchronen Observern mit Hilfe der Annotation @Priority eine Priorität zuzuweisen, um so eine bestimmte Reihenfolge zu erzwingen. Zusätzlich wurden asynchrone Events eingeführt. Da die Observer asynchroner Events in separaten Threads ausgeführt werden, muss der Erzeuger eines Events nicht mehr auf die Ausführung sämtlicher Observer warten. Zudem haben Fehler in asynchronen Observern keine Auswirkung auf den Aufruf der anderen asynchronen Observer des gleichen Events.
Endlich: Ein Standard für Security
Nicht zuletzt verdient auch die komplett neue Security 1.0 API einen genaueren Blick. Sie zielt auf die Beseitigung des Umstandes, dass Sicherheitsaspekte wie Authentifizierung oder die Überprüfung von Zugangsdaten bislang überwiegend durch die Hersteller der Application-Server zu implementieren waren. Hierdurch entstanden unterschiedliche proprietäre Lösungen, deren Anbindung nicht unerhebliche Aufwände bedeutete, falls im Unternehmen kein einfacher LDAP-Server, sondern beispielsweise eine proprietäre Benutzerverwaltung oder ein Authentication-Store eines Drittanbieters im Einsatz waren. Zwar wurde in Java EE 6 mit JASPIC eine Lösung zur Implementierung und Anbindung eigener Authentifizierungsmodule eingeführt. Diese erwies sich jedoch als recht komplex, war daher recht unbeliebt und wurde entsprechend selten eingesetzt. Zudem gilt sie inzwischen als veraltet.
Security 1.0 definiert nun standardisierte APIs für drei sicherheitsrelevante Grundkonzepte: Authentifizierungsmechanismus, Anbindung von Identity-Stores und Security-Context. Somit können diese Aspekte künftig von den Anwendungen selbst implementiert werden, anstelle auf eine Unterstützung und Konfiguration seitens des Application-Servers angewiesen zu sein. Dies bedeutet einen wichtigen Fortschritt für den Lebenszyklus von Anwendungen, was etwa am Beispiel von Cloud-Deployments oder in Docker betriebenen Anwendungen deutlich wird. Für Entwickler, die erst heute in die Welt von Java EE einsteigen, mag es erstaunlich erscheinen, dass so zentrale Aspekte erst in Java EE 8, und nicht schon vor langer Zeit standardisiert wurden.
Bislang unterstützten Servlet-Container zur Authentifizierung lediglich die Varianten Basic-, Digest-, Form- und Certificate-Authentication. Jenseits von JASPIC bestand für Anwendungsentwickler
kaum eine Möglichkeit, in den Authentifizierungsprozess einzugreifen oder weitere Mechanismen zur Authentifizierung zu unterstützen. Die neue Schnittstelle HttpAuthenticationMechanism ermöglicht es Entwicklern nun künftig beliebige Mechanismen zu implementieren. Die Installation eines solchen Mechanismus erfolgt dabei auf einfache Weise durch die Bereitstellung der jeweiligen Implementierung als CDI-Bean. Auf dieser Basis könnte beispielsweise eine tokenbasierte Authentifizierung mit JSON-Web-Token oder OAuth leicht umgesetzt werden. Spätere Releases der Security-API werden möglicherweise vorschreiben, dass Container selbst Implementierungen für solche populären Mechanismen verpflichtend mitbringen müssen. Security 1.0
schreibt jedoch zunächst lediglich eingebaute Mechanismen für Basic-Authenticaton und formularbasierte Authentifizierung vor.
Auf ganz ähnliche Weise wie im Falle des Authentifizierungsmechanismus führt Security 1.0 mit IdentityStore auch eine standardisierte Schnittstelle für die Anbindung von Systemen zur Benutzerverwaltung ein. Auch hier gilt, dass Anwendungsentwickler auf Basis der Schnittstelle die Anbindung beliebiger Systeme zur Prüfung von Zugangsdaten implementieren und dem Container als CDI-Bean bereitstellen können.
Als dritten Grundbaustein führt Security 1.0 schließlich auch einen (weiteren) SecurityContext ein. An dieser Stelle gibt es Überschneidungen mit diversen anderen APIs, wie etwa Servlet, EJB, JAX-RS oder JSF, die bereits über ähnliche Kontexte verfügen. Da nun jedoch eine dedizierte Security-API existiert, wird angestrebt diese bestehenden Kontexte mittelfristig aufzugeben und den neuen SecurityContext für die gesamte Plattform als zentralen, einheitlichen Zugang zu allen sicherheitsrelevanten Laufzeitinformationen zu nutzen.
Neben den hier besprochenen Features enthält Java EE 8 weitere Neuigkeiten in Bean-Validation 2.0, JPA 2.2, JSF 2.3, Web-Socket 1.1, Common-Annotations 1.3 und Java-Mail 1.6, die im Rahmen dieses Artikels jedoch nicht besprochen werden können.
Java EE wird Jakarta EE
Beinahe zeitgleich mit dem Release von Java EE 8 wurde bekannt, dass Oracle beabsichtigt seine federführende Rolle in der Entwicklung der Plattform aufzugeben und diese an die Eclipse Foundation zu übertragen. Dieser Schritt war zwar über längere Zeit von zahlreichen Vertretern der Community gefordert oder erhofft worden, kam für viele zu diesem Zeitpunkt dann aber doch recht überraschend. In jedem Fall bedeutet die Übertragung an die Eclipse Foundation eine Reihe signifikanter Veränderungen. So sollen unter anderem die bislang nur eingeschränkt zugänglichen TCKs (Test Compatibility Kit) künftig als Open Source zur Verfügung stehen. Dies wird praktisch jedermann erlauben, Implementierungen für die Plattform bereitzustellen und deren
Kompatibilität nachzuweisen. Hierdurch erhofft man sich eine stärkere Beteiligung der Community und mehr Wettbewerb unter den Implementierungen. Auch GlassFish, die bisherige Referenzimplementierung von Java EE, ist bereits an die Eclipse Foundation übergeben worden und heißt nun Eclipse Glassfish. Zudem soll es künftig nicht mehr nur eine einzige Referenzimplementierung der Plattform geben, sondern voraussichtlich mehrere. Die künftige Ausrichtung der Plattform, welche neuen Features entwickelt werden, sowie verschiedene organisatorische Einzelheiten werden fortan nicht mehr ausschließlich durch einzelne Hersteller bestimmt oder vereinbart. Stattdessen bekommt die Community ein gewichtiges Mitspracherecht. Insgesamt wird somit die ganze Plattform viel offener und ermöglicht deutlich mehr Beteiligung der Community. Ein neuer Prozess hierfür wird gerade innerhalb der Eclipse Foundation beraten. Eine Working Group namens “EE.next” wird den “Java Community Process for Java EE” ersetzen.
Während all dies offensichtlich zahlreiche Chancen bietet, ergeben sich aus diesen Veränderungen jedoch auch Risiken. So hat Oracle zwar offiziell angekündigt, sich auch weiterhin an der
Entwicklung der Plattform zu beteiligen, gleichzeitig ist jedoch damit zu rechnen, dass das Unternehmen den Umfang seines Engagements reduzieren wird. Hierdurch wird es notwendig werden, dass andere Hersteller, oder eben die Community, diese Lücke füllen. In diesem Zusammenhang bleibt abzuwarten, wie stark sich die Community hier tatsächlich einbringen wird. Unter anderem besteht die Hoffnung, dass Großunternehmen mit umfangreichen Entwicklerteams, die Java EE als Basis für zahlreiche Systeme einsetzen, einzelne Mitarbeiter abstellen, um die Weiterentwicklung der Plattform voranzutreiben.
Eine recht kontroverse Debatte verursachte die Namensgebung. Aufgrund der bei Oracle liegenden Namensrechte konnte der bisherige Name „Java EE“ nicht weitergeführt werden. Nach einigen Diskussionen über einen möglichen neuen Namen für die Plattform, und nachdem in der Community bereits zahlreiche Vorschläge gesammelt worden waren, wurde schließlich – erneut recht überraschend – angekündigt, dass die Plattform künftig unter einem neuen Top-Level-Project namens „Eclipse Enterprise for Java“ (EE4J) beheimatet sein wird. Dieser neue Name sorgte für sehr gemischte Reaktionen, insbesondere weil von vielen befürchtet wurde, EE4J würde auch der neue offizielle Name der Plattform werden. Dies ist jedoch nicht der Fall. Denn inzwischen wurde, dieses Mal unter Beteiligung der Community, ein neuer „Brand Name“ gefunden: Die Plattform wird künftig Jakarta EE heißen.
Die Problematik der Namensrechte betrifft auch die bislang in Java EE verwendeten Package-Namen, die mit javax beginnen. So ist bislang noch unklar, ob diese in EE4J bestehen bleiben können. Sollte dies nicht der Fall sein, müssten alle APIs in ein neues Package überführt werden, was die Rückwärtskompatibilität der Plattform vollständig zerstören würde. Dabei war gerade
diese Rückwärtskompatibilität eine bislang ganz besonders gepflegte Eigenschaft von Java EE, die von vielen Unternehmen als eine gewisse Sicherheit oder Bestandsschutz empfunden wurde. Es ist daher zu hoffen, dass in diesem Punkt eine Einigkeit zwischen Oracle und der Eclipse Foundation erzielt werden kann, so dass die bisherigen Package-Namen weitergeführt werden können, möglicherweise durch eine Lizensierung.
Eine interessante Entwicklung stellt derweil die Ernennung von Ivar Grimstad zum Leiter des Project Management Committees (PMC) dar. Grimstad ist gleichzeitig Specification-Lead von MVC 1.0 (JSR-371), das ursprünglich Bestandteil von Java EE 8 sein sollte, dann jedoch kurzfristig von Oracle fallen gelassen wurde. Da MVC 1.0 ebenfalls zur Eclipse Foundation transferiert wurde,
liegt somit nahe, dass es zukünftig in Jakarta EE integriert, und somit doch noch fester Bestandteil der Plattform werden wird.
MicroProfile als Innovationsmotor
Aktuell sind also noch zahlreiche organisatorische Fragen zu klären, so dass es mit der tatsächlichen Weiterentwicklung und einem ersten Release von Jakarta EE sicherlich noch eine Weile dauern wird. Gleichzeit entwickelt sich jedoch die Micro-Profile-Initiative zu einem Innovationsmotor für die Plattform. Die Initiative entstand ursprünglich im Spätsommer 2016 aus der Situation heraus, dass allgemein große Unsicherheit über die Zukunft und Weiterentwicklung von Java EE herrschten, da Oracle die Community über einen längeren Zeitraum im Unklaren über seine weiteren Pläne gelassen hatte. Gleichzeitig meldeten sich viele Stimmen, die forderten die Plattform müsse bessere Unterstützung für aktuelle Trends, wie Microservices oder Cloud anbieten. Als Reaktion hierauf vereinbarten einige Hersteller wie Red Hat, IBM, Payara und Tomitribe die Plattform gemeinsam, jedoch zunächst außerhalb des offiziellen Standardisierungsprozesses voranzutreiben, Ideen für die Weiterentwicklung zu sammeln, entsprechende Implementierungen kurzfristig bereitzustellen, und eine Standardisierung erst anschließend anzustreben. Erster Ansatzpunkt war dabei der Vorschlag eines neuen Java-EE-Profiles, das speziell für die Entwicklung von Microservices geeignet sein sollte und lediglich die Technologien JAX-RS, CDI und JSON-P umfasst. Für dieses Profile wurden unter dem Namen „MicroProfile 1.0“ eine ganze Reihe unterschiedlicher Implementierungen bereitgestellt, unter anderem Wildfly Swarm, Payara Micro, TomEE und Open Liberty, die Basis des WebSphereLiberty Application-Servers.
In der Zwischenzeit hat sich auch die MicroProfile Initiative der Eclipse Foundation angeschlossen, was eine enge Zusammenarbeit mit Jakarta EE ermöglicht. Zudem wurden in rascher Abfolge weitere Releases des MicroProfile vorgestellt und eine ambitionierte Roadmap veröffentlicht. Das im Herbst 2017 veröffentlichte MicroProfile 1.2 beinhaltet APIs für lange geforderte Erweiterungen, wie einen standardisierten Zugang zu Konfigurationsinformationen aus unterschiedlichen Quellen, sowie Unterstützung für Fault-Tolerance, Health-Checks, Metriken oder JSON Web-Tokens. Bereits Anfang 2018 folgte schon MicroProfile 1.3, das zusätzlich Unterstützung für Open-API (früher bekannt unter dem Namen Swagger) und Open-Tracing beinhaltet. Die Community hat nun die Möglichkeit, die vorgestellten Implementierungen des MicroProfile zu testen und entsprechendes Feedback zu geben. Stellen sich die vorgeschlagenen Erweiterungen als hilfreich heraus, könnten diese möglicherweise in eines der ersten Releases von Jakarta EE einfließen.
Fazit:
Unterm Strich ergibt sich eine zwiespältige Bewertung von Java EE 8. Einerseits zeigen sich manche Entwickler enttäuscht, die sich nach einer Wartezeit von immerhin vier Jahren (seit dem Release von Java EE 7) mehr Innovation erhofft hatten. Dies gilt insbesondere bezüglich einer besseren Unterstützung von Cloud-Szenarien und Microservices. Andererseits bringt Java EE 8 durchaus einige wichtige neue Features und Modernisierungen mit. An erster Stelle sind hier sicherlich die Unterstützung von HTTP/2, JSON Pointer, JSON Patch, HTTP Patch oder Server-Sent-Events zu nennen. Auch die Einführung einheitlicher APIs zur Umsetzung von Sicherheitsmechanismen war überfällig und ist sehr zu begrüßen. Nicht zuletzt wurden zahlreiche APIs auf sprachlicher Ebene modernisiert, indem sie nun Sprachfeatures unterstützen, die in Java SE 8 eingeführt wurden. Zudem ist positiv zu bewerten, dass nach der im Jahr 2016 herrschenden Verunsicherung bezüglich der Zukunftsperspektive der Plattform mit Java EE 8 nun letztlich doch ein weiteres Release zustande gekommen ist, welches zudem einen ausgezeichneten Startpunkt für die Weiterentwicklung durch die Eclipse Foundation darstellt.
Auf genau diese Weiterentwicklung werden Entwickler jedoch noch ein wenig warten müssen. Denn bevor ein erstes Release von Jakarta EE zu erwarten ist, müssen noch einige organisatorische und rechtliche Dinge geklärt werden. Zudem ist zu erwarten, dass Jakarta EE 1.0 mehr oder weniger identisch mit Java EE 8 sein wird. Ziel dieses Releases dürfte es sein, den vollständigen und erfolgreichen Übergang zur Eclipse Foundation nachzuweisen. Gleichzeitig arbeitet jedoch die MicroProfile Initiative in bisher ungekanntem Tempo an der Entwicklung möglicher
neuer Features. Es wird daher nun ganz besonders auch auf die Community ankommen, hierzu Feedback zu geben und das über lange Zeit teils heftig geforderte Mitspracherecht nun auch tatsächlich zu nutzen, um Einfluss auf die Ausrichtung der kommenden Releases zu nehmen. Auf diese Weise könnte die bewährte, auf breiter Basis eingesetzt Java EE Plattform unter neuem Namen – und in rascheren Zyklen als bisher – an die Anforderungen zeitgemäßer Enterprise-Anwendungen angepasst werden, und somit einer rosigen Zukunft entgegensehen.
Thilo Frotscher arbeitet als freiberuflicher Software-Architekt und Trainer. Als Experte für Enterprise Java, APIs und Systemintegration unterstützt er seine Kunden überwiegend durch Projektarbeit, Reviews oder Schulungen. Thilo ist (Co-) Autor mehrerer Bücher zu Java EE, (Web) Services und Systemintegration, hat zahlreiche Fachartikel veröffentlicht und spricht regelmäßig auf Fachkonferenzen, auf Schulungsveranstaltungen oder bei Java User Groups.
http://www.frotscher.com
feedback@frotscher.com
https://twitter.com/thfro
