Gleich auf mehreren Konferenzen hält unser Geschäftsführer Dirk Weil in diesem Herbst Vorträge rund um das Thema Jakarta EE.

JCON WORLD 2023, online

• Speaker: Dirk Weil
• Thema: Enterprise Framework Battle: Quarkus vs. Spring Boot
• Termin: 22.11.2023 14:00
• Details

Gleich auf mehreren Konferenzen hält unser Geschäftsführer Dirk Weil in diesem Herbst Vorträge rund um das Thema Jakarta EE.

EclipseCon 2023, Ludwigsburg

• Speaker: Dirk Weil
• Thema: Pimp your Jakarta EE applications
• Termin: 16.10.2023, 
• Details

Jakarta EE, auch bekannt als Java EE, ist eine weit verbreitete und stabile Plattform für Unternehmensanwendungen. Allerdings haftet ihr der Ruf an, veraltet und träge zu sein – ganz zu Unrecht! Mit den aktuellen Versionen und Implementierungen gewinnt die Plattform an Schwung. Wer seine Anwendungen zu Jakarta EE 10+ migriert, kann von schneller Entwicklung und leichtgewichtigen Runtimes profitieren.

Allerdings liegen wegen des Namenswechsel in einigen Paketen (javax -> jakarta) ein paar Steine im Weg, die aber mit Tools wie OpenRewrite weggeräumt werden können. In diesem Vortrag werde ich demonstrieren, wie Anwendungen schnell von Java EE 8 zu Jakarta EE 10+ migriert und auf leichtgewichtigen Laufzeiten wie WildFly Bootable Jar, Open Liberty oder Quarkus ausgeführt werden können.

Die Veröffentlichung von Jakarta EE 10 liegt nun knapp ein Jahr zurück. Wie hat sich die Enterprise-Welt in dieser Zeit verändert? Ich möchte in diesem Vortrag die Version 3 des beliebten Jakarta-Enterprise-Frameworks Quarkus vorstellen. Diese wurde bereits im April 2023 veröffentlicht und stellte damit die Basis auf Jakarta EE 10 um.

Die älteren Quarkus-Versionen verwendeten schon immer eine eigenständige Implementierung der Context and Dependency Injection. Ein wichtiger Teil von Jakarta EE 10 ist unter anderem die Aufteilung von CDI und die Definition einer reduzierten Core-Variante. Damit ist es nun auch Frameworks wie Quarkus möglich, eine vollständige Kompatibilität erreichen zu können.

Neben den Möglichkeiten von Jakarta EE 10 stellt Quarkus noch weitere Technologien zur Verfügung. Diese sind unter anderem in der Microprofile Spezifikation definiert. Auch hier stellt Quarkus seine Basis auf die aktuelle Version 6 um.

Darüber hinaus wurde ein neuer Release-Zyklus mit der Version 3.2 geschaffen. Das Framework bekommt hiermit nun endlich ein Long-Term-Release, welches mit entsprechenden Updates über einen längeren Zeitraum versorgt wird.

Spring Boot ist weit verbreitet und für viele “die” Plattform für Server-Anwendungen und Microservices. Das jüngere Quarkus nimmt für sich in Anspruch, die Basis für ultra-schnelle Anwendungen mit kleinem Footprint zu sein. Beide Frameworks haben ein beeindruckendes Ökosystem und versprechen beste “Developer Experience”.

Aber Papier bzw. Webseiten sind geduldig, also probieren wir’s einmal aus. In diesem Talk wird eine zwar überschaubare, aber realistische Aufgabe mit beiden Frameworks gelöst. Wir vergleichen den Code und schauen, wo Gemeinsamkeiten sind und wo die Frameworks die Nase vorn haben.

Anwendungen sind nicht unbegrenzt multitasking-fähig. Anfragen zu blockieren, bis das Ergebnis feststeht, bedeutet viele Treads. Viele Threads verbrauchen viele Ressourcen. Der vermeintliche Ausweg und derzeitiges Silver-Bullet: Reactive Programming. Damit sparen wir Threads bis zum Ultimo, schreiben dafür Programmcode, den wir teilweise selbst nach 2 Wochen nicht mehr verstehen, und handeln uns andere Schwierigkeiten – pardon: Anforderungen ein, die wir vorher gar nicht hatten.

Wir betrachten in diesem Talk aktuelle Lösungen reaktiver Programmierung bspw. in Quarkus und Helidon, bewerten Programmcode sowie Laufzeitvorteile und vergleichen das Ganze mit Lösungen auf Basis virtueller Threads (Project Loom) mit gradlinigem Programmcode.

Funktionale Programmierung erlebt immer wieder mal einen kleinen Hype, aber so richtig durchgesetzt hat sie sich ja nicht. Oder doch? Kritiker sehen darin das Teufelswerkzeug egozentrischer Egomanen, die in ihren Elfenbeintürmen mit Schadenfreude lesbaren Code bis zur Unkenntlichkeit verschandeln, Befürworter erkennen in ihr den heiligen Gral, das wirklich einzige Paradigma, das uns auf dem Rücken der Mehrkernprozessoren in eine goldene Zukunft reiten lässt.

Wie sieht es in der Praxis aus? Kann das weg, oder ist das Kunst? Wie immer liegt die Wahrheit vermutlich irgendwo dazwischen. Begleiten Sie mich bei einem subjektiven Blick auf die Thematik – auch wenn Funktionale Programmierung vielleicht nicht die Welt im Sturm erobern mag, so sind ihre Themen und Probleme dennoch spannend.

Nicht selten ist der Blick über den Tellerrand ein wahrer Augenöffner, der das eigene Programmieren und Modellieren nachhaltig positiv.

Man muss sich nicht komplett umstellen, um von Funktionaler Programmierung zu profitieren. Wir werden sehen, dass man sie auch in “normalen” Sprachen wie Java oder Kotlin wohldosiert und gewinnbringend einsetzen kann. Und für alle,
die gerne knobeln und es ein wenig esoterisch mögen, für die haben wir auch noch ein wenig Clojure im Gepäck.

Was sind denn eigentlich Prozessanwendungen? Wie unterscheiden sie sich von den klassischen Anwendungen auf der JEE-Plattform? Und was ist eigentlich BPMN? Alle diese Fragen sollen in diesem Vortrag geklärt und besprochen werden. Und noch viel mehr als das. Ich möchte Ihnen die Funktionsweise solch einer Prozessanwendung und die Schritte die zur Entwicklung einer Anwendung notwendig sind aufzeigen.

Wenn wir von einer prozessorientierten Modellierung sprechen, dann müssen wir uns auch mit aufgabenorientierten Anwendungen auseinandersetzen. Denn Prozesse bestehen zum Einen aus automatisierten Abläufen und zum Anderen aus manuellen Aufgaben, die von “realen” Personen ausgeführt werden. All das wird im Vortrag anhand einer Beispielanwendung gezeigt.

In der Welt von JavaScript gibt es eine Vielzahl von Bibliotheken und Frameworks. Aber es gibt drei Frameworks für die Erstellung von Webanwendungen, von denen jeder Frontend-Entwickler schon einmal gehört hat: Angular, React und Vue.js.

Angular ist ein vollwertiges Frontend-Framework, React ist eine UI-Bibliothek und Vue.js nennt sich selbst ein progressives Framework.

Sie können fast austauschbar verwendet werden, um Front-End-Anwendungen zu erstellen, aber sie sind nicht zu 100 Prozent gleich, daher ist es sinnvoll, sie zu vergleichen und ihre Unterschiede zu verstehen.

Im Vortrag geht es um die Architektur der Frameworks und wir betrachten außerdem die Aspekte Basis-Technologien, Popularität, Ökosystem, Lernkurve und versuchen einen Blick in die Zukunft der JavaScript-Frameworks.

Lange haben wir auf das neue Release der Jakarta Enterprise-Plattform warten müssen. Mit dieser Version gibt es endlich wieder neue Funktionalitäten und Änderungen. Welche Neuerungen haben es in die Version 10 der Jakarta Enterprise-Plattform geschafft? In diesem Talk wollen wir einen kurzen Überblick darüber geben.

Ein Fokus der neuen Jakarta EE-Version liegt auf der Context and Dependency Injection. Die einzelnen Teile der Spezifikation sollen hier so gut wie möglich mit CDI zusammenarbeiten. Im Bereich der Concurrency wurde dazu beispielsweise ein Äquivalent zu @Asynchronous geschaffen. Das Bereitstellen von Instanzen zum Zugriff auf den Anwendungskontext wurde ebenfalls auf CDI ausgelegt. Dazu wurde die Verwendung von @Context als deprecated markiert.

Für die Realisierung von Microservices wurde ein neues Core-Profil geschaffen. Es beinhaltet unter anderem das neue CDI Lite, auf das wir auch einen Blick werfen wollen.

Darüber hinaus schauen wir uns Jakarta Persistence an. Hier gibt es nun UUIDs z. B. für Primärschlüsselattribute. Des Weiteren stehen jetzt weitaus mehr Funktionen in JPQL zur Verfügung, unter anderem auch Methoden für den Umgang mit LocalDate- und LocalTime-Objekten.

Auch im Bereich der Webanwendungsentwicklung hat sich einiges getan. So wurde für Jakarta Faces eine neuer @ClientWindowScoped eingeführt. Darüber hinaus besteht die Möglichkeit, über reines Java eine @View zu implementieren.

Natürlich betrachten wir in diesem Vortrag auch die Entwicklungen der aktuellen Versionen der Application Server. Und schauen, wie und wann man die neue Jakarta EE Version einsetzen kann.

Die Verwendung einer NoSQL-Datenbank in Enterprise-Java-Projekten war bisher immer mit einem gewissen Vendor-Lock verbunden. Um die Funktionalitäten nutzen zu können ist es notwendig den jeweiligen Client in seine Anwendung zu integrieren. Damit einher geht auch das Erlernen einer neuen API um die Operationen auf der Datenbank ausführen zu können.Aus Sicht von Enterprise-Projekten ist diese Herangehensweise nicht unbedingt vorteilhaft. Man möchte auf Standards setzen um die Anwendung möglichst zukunftssicher zu machen.

Darüber hinaus möchte man bei einem Technologiewechsel nicht gleich den gesamten Persistenz-Stack austauschen und ggf. neu erlernen müssen. All das ist in der relationalen Welt bereits Normalität. Wir verwenden Objekt-Relationales-Mapping und eine wohl-definierte Schnittstelle zur Ausführung der Datenbank-Operationen.Genau an diesem Punkt setzt die neue Spezifikation Jakarta NoSQL an, um auch in der JEE-Welt einen einheitlichen Standard zu definieren. Eclipse JNoSQL ist die dieser Spezifikation zugrundeliegende Referenz-Implementierung. In diesem Vortrag möchte ich an einem kurzen Beispiel deren Einsatz auf Basis einer Key-Value-basierten (Redis) und einer dokumenten-orientierten (MongoDB) NoSQL-Datenbank zeigen.

Seit Mitte September 2021 steht mit Java 17 das aktuelle LTS-Release von Java zur Verfügung. Viele Projekte nutzen aber noch Java 8 oder aber schon Java 11, ohne vielleicht wirklich die neuen Features dieses vorhergehenden LTS-Releases aktiv zu nutzen. Also sollten wir einmal zusammenfassen, was es aus der Sicht des “typischen” Java-Entwicklers bzw. des “normalen” Java-Projektes an interessanten Neuerungen gegeben hat. Stichworte sind Variablen-Deklaration mit var, switch als Ausdruck, Text-Blöcke usw. Was ist denn aus dem Modul-System JPMS geworden?

Und gibt es auch “fundamental” Neues, wie es die Lambda-Ausdrücke bei Java 8 waren? Diese Frage führt uns zu dem Hauptthema des Vortrags, nämlich den algebraischen Datentypen aka Records und Sealed Classes und deren Nutzung beim Pattern Matching. Im Ausblick schauen wir auf Kommendes: mehr Pattern Matching und die “Wiederauferstehung” von Vector<E>. — Realisierung von Prozessanwendungen auf Basis von Jakarta EE und der Camunda BPMN Platform.

Was sind denn eigentlich Prozessanwendungen? Wie unterscheiden sie sich von den klassischen Anwendungen auf der JEE-Plattform? Und was ist eigentlich BPMN? Alle diese Fragen sollen in diesem Vortrag geklärt und besprochen werden. Und noch viel mehr als das. Wir möchten Ihnen die Funktionsweise solch einer Prozessanwendung und die Schritte, die zur Entwicklung einer Anwendung notwendig sind, aufzeigen.

Wenn wir von einer prozessorientierten Modellierung sprechen, dann müssen wir uns auch mit aufgabenorientierten Anwendungen auseinandersetzen. Denn Prozesse bestehen zum einen aus automatisierten Abläufen und zum anderen aus manuellen Aufgaben, die von “realen” Personen ausgeführt werden. All das wird im Vortrag anhand einer Beispielanwendung gezeigt.

In Softwareentwicklungsprojekten stellt sich häufig die Aufgabe, Teile der Gesamtanwendung so an die gewünschte Umgebung anpassbar zu machen, dass algorithmische Änderungen auch ohne ein neues Deployment/Release in Betrieb genommen werden können. Natürlich kann ein solches Szenario durch die Entwicklung einer eigenen Kommando- oder Formelsprache gelöst werden, 

aber einfacher und vermutlich mächtiger ist die Nutzung von Skriptsprachen wie Beanshell, Groovy oder JavaScript. Diese sind alle bereits vorhanden und laufen auf der JVM. Der Talk führt in die Nutzung von Skriptsprachen in Java ein, demonstriert dies mit einigen Beispielen und wirft abschließend einen Blick auf die Performanz der Skripte.

Enterprise-Anwendungen müssen kleiner werden. Die Zeit großer Monolithen ist für viele vorbei – Microservices versprechen kürzere Release-Zyklen und leichtere Innovation. Wer nun der Meinung ist, dass das mit Jakarta EE nicht geht, liegt falsch. MicroProfile ergänzt das Serverangebot um Dinge, die im verteilten Cloud-ready-Umfeld benötigt werden. Konfiguration und Überwachung werden damit ebenso zur Kleinigkeit wie fehlertolerante Kommunikation zwischen Services. 

Mit MP 4.0 kommen u. a. Reactive Messaging und GraphQL hinzu. Cool ist zudem, dass das Ganze sowohl mit klassischen Servern wie WildFly oder Open Liberty funktioniert, aber auch mit Frameworks wie Quarkus implementiert werden kann.

Quarkus ist ein Framework für Enterprise-Anwendungen, Microservices und Self-contained Systems, über das wir im Expertenkreis schon früher berichtet haben – zuletzt vor über einem Jahr. Zeit für ein Update, denn das Quarkus-Ökosystem wächst rasant. Wir schauen u. a. auf Continuous Testing und Dev Services sowie die Extensions für Panache, Flyway, Picocli und GraphQL. Kaum Folien, viel Code. Lassen Sie sich überraschen!

Enterprise Java wird in diesem Jahr 22 – zumindest, wenn man den Standard betrachtet, der eine teilweise bewegte Vergangenheit mitbringt. Die von Sun Ende 1999 veröffentlichte Version 1.0 der J2EE (“Java 2 Platform, Enterprise Edition”) war aus heutiger Sicht viel zu kompliziert, umfasste aber durchaus bemerkenswerte Konzepte. Ab der Version 5 (nun “Java EE”) wurde die Plattform leichtgewichtig durch Dependency Injection à la Spring und die Nutzung von Annotationen statt XML-Deskriptoren. Bei Java EE 7 stand dann Oracle als Linzenzinhaber vermeintlich auf der Bremse: Die Weiterentwicklung stagnierte und viele sagten der Plattform einen baldigen Tod voraus. Die Version 8 wurde dann doch in 2017 veröffentlicht und dann – glücklicherweise – die Übergabe des Gesamtprojektes an die Open-Source-Organisation Eclipse Foundation durchgeführt.

Aus Copyright-Gründen ändert sich der Name nun ein weiteres Mal in “Jakarta EE” und zudem müssen Paketnamen geändert werden. Dies bedeutet zwar einen “Breaking Change”, bietet aber gleichzeitig die Chance, veraltete Anteile zu entfernen. Die eng mit JEE verknüpfte Open-Source-Spezifikation MicroProfile macht die Plattform bereit für Cloud und Microservices.

Wir schauen im Vortrag auf den derzeitigen Stand und auf das angekündigte Release Jakarta EE 10.

Serverless ist zurzeit eines der populärsten Cloud-Themen in der Welt der Softwareentwicklung. Mehr und mehr Unternehmen nutzen Serverless um schneller Innovationen voranzubringen und die operativen Aufgaben an einen Cloud-Anbieter abzugeben. Aber welche Systeme können wir mit Serverless Funktionen eigentlich erstellen? Und wie kann ich mit Serverless Funktionen eigentlich starten? In diesem Vortrag werden wir uns zum einen die Grundlagen von Serverless Funktionen anhand von AWS Lambda anschauen. Zum anderen werden wir typische Anwendungsfälle für Serverless Systeme kennenlernen.

Anstatt dies alles theoretisch über Folien zu lernen, werden wir in den Code und verschiedene Architekturen sehen, um ein besseres Verständnis der folgenden Themen zu erhalten:

– AWS Lambda: Wie schreibe ich eine Serverless Funktion in Node.js und Java?
– Skalierbare Serverless REST APIs bauen
– Zuverlässig Daten speichern und behandeln
– Verarbeiten von Nachrichten aus Queues

Eine komplexe Großrechner-Anwendung (der Monolith) für das gesamte Kerngeschäft, stark verwobener COBOL- und Java-Code und eine sehr große, unternehmensweite Datenbank: unser langjähriger Kunde hatte einen Handlungsbedarf. Im Rahmen eines Consulting-Einsatzes wurde eine Ziel-Architektur für die Migration der Unternehmens-Anwendung konzipiert und als Referenz-Implementierung evaluiert. Als Methodik für die Zusammenarbeit von Fachabteilungen und Anwendungsentwicklung wurde das Domain-Driven Design (DDD) eingeführt. 

Die technische Umsetzung erfolgt durch verteilte Software-Komponenten auf Basis der Java / Jakarta Enterprise Edition (JEE). Jens Seekamp berichtet von seinen Erfahrungen in diesem Großkundenprojekt und geht auch auf die durchgeführten Trainings-Maßnahmen zur Qualifizierung der involvierten Software-Entwickler ein.

*Supersonic Subatomic Java” verspricht der neue Stern am Himmel der Microservice-Frameworks namens Quarkus. Tatsächlich lassen sich mit Quarkus schnell und einfach Services erstellen, die klein, performant und reaktiv sind, perfekt in die Cloud passen und dennoch das JEE-Programm-Modell weiter nutzen. Quarkus basiert auf MicroProfile, einem Subset der Jakarta EE mit diversen Ergänzungen für die Erstellung verteilter, cloud-ready (Micro-)Services. 

Devs werden den Developer Mode für schnelles, iteratives Entwickeln schätzen und Ops die nahtlose Integration in Container-Technologien sowie die ultraschnellen Startzeiten im Native Mode.

Dieser Talk gibt einen Überblick über Quarkus inklusive diverser Live-Demos.

-> Artikel zum Thema

Containerbasierte Umgebungen wie Docker sind im Mainstream angekommen. Orchestrierungsplattformen wie Kubernetes versprechen eine skalierbare Verwaltung von Containern. Es spricht einiges dafür, dass aus einer Menge von Java-Quellen zukünftig nicht ein JAR oder WAR gebaut wird, sondern eben ein Container-Image. Damit einher geht eine Neuausrichtung des Entwicklungs- und Deploy-Prozesses weg von manuellen Arbeitsschritten hin zu einer eher industriellen Vorgehensweise mit wiederholbaren und nachvollziehbaren Schritten. 

Dieser Vortrag zeigt, wie mit Docker, Kubernetes, Git und Jenkins effizient Anwendungen in Produktion gebracht werden können. Einige Folien, viel Live-Demo.

Die klassische Enterprise-Welt nutzt Server wie WebSphere oder JBoss/WildFly, um darauf große WAR- oder EAR-Files zu deployen. Wenngleich dieses Modell im traditionellen Server-Betrieb sehr gut funktioniert, so erscheint es doch recht schwergewichtig und wenig geeignet für moderne, verteilte – ggf. Cloud-basierte – Services. „Mit Java EE kann man moderne Sachen nicht machen“ ist eine leider verbreitete Ansicht. Vermeintlich leichtgewichtige Alternativen locken – allen voran Spring Boot. Aber stimmt das so? Bei genauerer Betrachtung erscheinen die konkurrierenden Konzepte nahezu deckungsgleich. 

Zudem bieten das Microprofile und diverse darauf basierende Implementierungen genau die vielfach vermissten Leichtgewichteigenschaften:

Kein separater Server, kleiner Footprint, einfache Konfiguration, Health Monitoring u. v m. Angenehm ist, dass das Programmkonzept davon unberührt bleibt, d. h. EE-Entwickler können sehr schnell leichtgewichtige Services entwickeln, ohne komplett umlernen zu müssen.

Die klassische Enterprise-Welt nutzt Server wie WebSphere oder JBoss/WildFly, um darauf große WAR- oder EAR-Files zu deployWebanwendungen in JEE werden mit JSF implementiert, ist es doch das Framework welches im Standard vorhanden ist und seit Jahren erfolgreich in Projekten eingesetzt wird. Wirft man einen Blick über den Tellerrand, kommt man dieser Tage jedoch an einem ganz anderen Framework nicht vorbei: Angular. Also warum nicht mal Angular? Oder vielleicht besser: “Warum”? In dieser Session schauen wir uns die Beweggründe an, warum auch für JEE-Projekte ein JavaScript-Frontend interessant sein kann und bringen in einem praktischen Beispiel “einfach” und “mal eben” JEE und Angular zusammen. 

Wie einfach ist die Verwendung von JavaScript-Anwendungen im Zusammenspiel mit Java EE? Welche Stolpersteine gibt es auf Java-Seite?

Und worauf sollte geachtet werden, wenn Java als Backend für eine JavaScript-Anwendung verwendet werden? Wenngleich dieses Modell im traditionellen Server-Betrieb sehr gut funktioniert, so erscheint es doch recht schwergewichtig und wenig geeignet für moderne, verteilte – ggf. Cloud-basierte – Services. „Mit Java EE kann man moderne Sachen nicht machen“ ist eine leider verbreitete Ansicht. Vermeintlich leichtgewichtige Alternativen locken – allen voran Spring Boot. Aber stimmt das so? Bei genauerer Betrachtung erscheinen die konkurrierenden Konzepte nahezu deckungsgleich. 

Durch Java EE haben wir in der Vergangenheit verlernt, durchgängig objektorientiert zu entwickeln. Viele Anwendungen nutzen anämische Fachobjekte und implementieren die Geschäftslogik in separate Services, was einen Bruch der Konzepte der Objektorientierung darstellt. Kann man das denn mit Java EE / Jakarta EE richtig machen – lässt JEE DDD zu? 

Die Antwort ist ein klares “Ja”, wenn man die ausgetretenen Pfade der massenhaften Tutorials verlässt. In diesem Vortrag wurde gezeigt, wie die Building Blocks des DDD auf JEE-Klassen abgebildet werden können, um übersichtliche und wartbare Anwendungen zu erhalten.  

Die Java-EE-Welt hat sich lange um das Thema Batchverarbeitung gedrückt, was zur Entwicklung von Frameworks wie Spring Batch geführt hat. Die Hintergrund-Verarbeitung von (i. d. R.) Massendaten ist aber ein wichtiger Bestandteil vieler Enterprise-Anwendungen, dem die Integration von „Batch Applications for the Java Platform“ (JSR 352) in den Standard Java EE / Jakarta EE Rechnung trägt. 

Der Vortrag stellt die Grundzüge der Offline-Verarbeitung mit Jobs, Steps, Chunks, Splits, Flows, Decisions etc. dar und demonstriert einige Beispiele auf dem Java-EE-Server WildFly 16.