Einer unserer Kunden betreibt eine Reihe von Enterprise-Anwendungen, die vor knapp 15 Jahren entstanden sind. So positiv die Tatsache ist, dass die Anwendungen ihren Zweck immer noch gut erfüllen, so ist damit aber auch ein Problem verbunden: Die Anwendungen sind technisch auf dem Stand von damals. Sie nutzen J2EE 1.4 und laufen auf einem BEA WebLogic 8. Für diesen – damals topaktuellen – Server und die Laufzeitumgebung Java 1.4 gibt es keinen Support mehr. Die Unternehmensstrategie zeigt klar auf Java 7+ und JBoss bzw. WildFly als Application Server. Womit sich die Frage stellt: Sind solche technisch in die Jahre gekommene Anwendungen überhaupt migrierbar und kann man dabei auch noch einen Application-Server-Wechsel wagen?

Jeder kennt Systeme mit schlechter Codequalität und Architektur – und die sind schwer änderbar. Aber andere Faktoren sind oft noch viel wichtiger. Was ist mit Tests? Oder dem Releaseprozess?

Weld ist eine Implementierung der erstmals im Dezember 2009 vorgelegten Spezifikation für Contexts and Dependency Injection (CDI). Die mittlerweile 12. Alpha-Version von Weld 3.0.0 ist den Entwicklern zufolge der bislang wichtigste Meilenstein auf dem Weg zum finalen Release: Sie stellt eine Referenzimplementierung des Spezifikationsentwurfs Contexts and Dependency Injection for Java 2.0 (EDR1) dar.

Wie kann die Umstellung einer hochverfügbaren Live-Plattform mit mehr als 100 Application-Servern von JEE 6 auf JEE 7 ohne Ausfallzeiten gelingen? Und wie wird Continuous Delivery während der gesamten Projektlaufzeit unterstützt, wenn 70 Entwickler gleichzeitig Änderungen an der Codebasis durchführen? Basierend auf einem Projekt bei GameDuell beschreibt dieser Praxisbericht die technischen Maßnahmen und Anpassungen des Build- und Release-Prozesses, um die gestellten Anforderungen zu erfüllen und die Migration von 300 Maven-Modulen erfolgreich abzuschließen.

In dieser dreiteiligen Artikelserie soll eine Lösung vorgestellt werden, wie man ein zentralisiertes Exception Handling für eine REST API aufbauen und dieses zusätzlich mit BeanValidation koppeln bzw. ergänzen kann. Dazu sollen ausschließlich Java-EE-7-Standards (JAX-RS, JAXB für die Serialisierung in XML oder JSON, usw.) verwendet werden, weswegen keinerlei zusätzliche Libraries erforderlich sind.

JSON-P, die Standard-API für die JSON-Verarbeitung in Java EE 7, wird für Java EE 8 einer Überarbeitung unterzogen. Nun steht ein erster Entwurf der Spezifikation JSON-P 1.1 (JSR 374) zur Ansicht bereit.

Deutschland ist Java-EE-Land. Das bestätigen uns immer wieder Entwickler, die überwiegend im US-amerikanischen Markt oder auch in Großbritannien unterwegs sind. Dort haben sich, seit der großen Java-EE-Komplexitätskrise vor dem Erscheinen von Java EE 6 (im Jahre 2009), die meisten in Richtung alternativer Frameworks, vorwiegend Spring, orientiert. Und sind dort auch geblieben.

In Java-EE-Anwendungen waren Event-basierte Architekturen bislang nicht sehr verbreitet, weil es noch keine standardisierte Unterstützung für fachliche Events gab. Mit CDI Events hat sich das geändert. Anhand einer Live-Demonstration zeigt Thilo Frotscher (Freiberufler), wie sich Event-basierte Architekturen auf einfache Weise mit Java EE entwickeln lassen.

Vor rund zwei Jahren erschien die Java EE 7-Plattformspezifikation in ihrer finalen Version. Nun wurde ein erstes, seit Mitte Mai 2015 in der Entwicklung befindliches Maintenance Release veröffentlicht.

Nashorn ist eine mit Java programmierte JavaScript Engine, die mit Java 8 veröffentlicht wurde. In seiner Session auf der JAX 2015 führte Java Champion Adam Bien vor, was mit ihr im Java-EE-Bereich so alles möglich ist.

Seit fast einem Jahr befindet sich CDI 2.0, die nächste wichtige Iteration des Standards für Dependency Injection in Java, unter dem JSR Nummer 365 im Java Community Process. Nun hat die Expertentruppe um die Spec Leads Antoine Sabot-Durand und Pete Muir (beide Red Hat) der Community ein frühes Entwurfspapier zur Betrachtung freigegeben.

Microservices sind aktuell einer der Trends in der Softwarearchitektur. Natürlich sollte man mit solchen Buzzwords und Hype-Themen vorsichtig sein. Allerdings gibt es bereits einige Branchen-Größen (z. B. Netflix), die diesen Architekturstil produktiv einsetzen. Zudem ist mittlerweile auch eine Vielzahl von Bibliotheken im Microservices-Umfeld entstanden.

Die Frage, was denn nun besser sei – Spring oder Java EE – ist so alt wie die Technologien selbst. Doch ist sie überhaupt gerechtfertigt?

Der Java Message Service (JMS) ist ein wichtiger Bestandteil von Java EE, da er auf eine zuverlässige asynchrone Kommunikation zwischen den Komponenten verteilter Anwendungen abzielt. Zusammen mit einigen anderen Java Specification Requests (JSRs) aus Java EE 7 kann sich JMS 2.0 dem Wohlwollen der Community erfreuen. Einige Ausbesserungen, die sich das Team rund um den Projektverantwortlichen Nigel Deakin vorgenommen hat, fanden jedoch keinen Eingang in die aktuelle Version. Nun ist die Meinung der Community in Bezug auf JMS 2.1 gefragt.

Die in der Java-Community erst vor kurzem wieder einmal aufgeflammte Diskussion „Spring versus Java EE“ geht in eine neue Runde. Oder vielleicht besser gesagt: Darüber hinaus. Denn wie Lukas Eder auf dem jOOQ-Blog klar stellt, ist das Problem aus seiner Sicht die Schwäche des (de facto) existierenden Java EE-Standards sowie die zur Zeit nicht existente Alernative zu Spring und Java EE.

Red Hat hat die Verfügbarkeit von WildFly 9 CR2 bekannt gegeben. Die finale Version kann in den nächsten Wochen erwartet werden, so Jason Greene, Leiter des WildFly Application-Server-Projektes.

Mitunter geraten Java Specification Requests (JSR) auf verschlungene Pfade – um nach einer langen Wanderung dennoch ans Ziel zu gelangen. Beispiel hierfür ist der JSR 359: SIP Servlet 2.0. Die 2012 gestartete Spezifikation ist vor Kurzem mit dem finalen Release zu ihrer vorläufigen Vollendung gelangt. Worum geht es dabei?

Im Beitrag „Java EE 7 failed to enter the market“: Warum Spring 5 ohne Java EE 7 plant haben wir auf JAXenter über Jürgen Höllers Ausblick auf Spring 5 und sein Statement zur Situation um Java EE 7 berichtet. Spring-Data-Entwickler Oliver Gierke steuert in seinem Kommentar einige Gedanken bei und stellt klar: Von einem „Spring versus JavaEE“ zu reden, ist faktisch eigentlich falsch!

Java EE 7 ist noch nicht in der Industrie angekommen – das Spring Framework wird sich deshalb in seiner nächsten Version 5 auf die Unterstützung von JDK8 basierten Java EE 6 Server konzentrieren. Mit dieser Kernbotschaft stellt Spring-Miterfinder Jürgen Höller die Marschroute für Spring 5 vor.