Tech Talk: Quarkus – ein neuer Java Technology Stack

Im neuesten Tech Talk hat unser Faktor Zehn Kollege Tri seine Erfahrung mit dem Java Framework Quarkus präsentiert. Dieses wurde in Hinblick auf Integration von Linkki und Vaadin für ein Kundenprojekt evaluiert. Im folgenden Blogartikel erhalten Sie einen Einblick in den Tech Talk und finden einen Link zum GitLab Repository des Java Codes.

Quarkus: ein neuer Java Technology Stack

Quarkus ist ein recht junges Framework (Release 1.0.0 wurde erst im November 2019 veröffentlicht) um moderne Java Applikationen zu entwickeln. Die Entwickler und Entwicklerinnen von Quarkus wollen sich mit 3 Aspekten von der Konkurrenz – allen voran Spring Boot – abheben:

1) Produktive Applikationsentwicklung

Wie das Zitat besagt, baut Quarkus auf oder integriert sehr viele andere bekannte Java Frameworks und Libraries um eine produktive und schnelle Entwicklung von Applikationen zu ermöglichen. Um einige Beispiele zu nennen:

• Für REST benutzt Quarkus
  • JAX-RS als Spezifikationsstandard für Schnittstellenbeschreibung
  • RESTEasy als Implementierung
  • Ein eigenes Quarkus Sub-Projekt QSON für JSON Serialisierung (andere Libraries wie Jackson wurde aus Performance Gründen nicht genommen)
• Für Object-Relational-Mapping (ORM):
  • JPA als Spezifikationsstandard
  • Hibernate als Implementierung
• Für Dependency Injection:
  • Java CDI als Standard
  • ArC als Quarkus eigene Implementierung

Viele weitere Frameworks/Libraries sind für Quarkus verfügbar. Generell werden solche integrierbaren Technologien als Quarkus Extensions designiert. Sogar die Konkurrenz Spring ist verfügbar als Extension, um z.B. Spring Annotationen in Quarkus verwenden zu können.

2) Kubernetes/Docker Container

Quarkus ist ausgelegt mit einem Kubernetes-/Container-first Ansatz. Zum einen bedeutet es, dass das Quarkus Team selbst Extensions bereitstellt für

• das Bauen von Docker Images
• das Erzeugen von Kubernetes Manifest Dateien
• die Aktivierung von Liveness/Readiness Endpunkten
• … und viele andere Themen rund um Kubernetes

Zum anderen ist der Maven/Gradle Build-Prozess von Quarkus standardmäßig so ausgelegt, dass kein großes Über-JAR erzeugt wird (wie bei Spring Boot) sondern die gebaute Applikation in einer „exploded“ Ordnerstruktur geliefert wird. Ein Maven Beispiel:

Die JARs von 3rd Party Libraries werden in getrennten Ordnern zum JAR mit den Applikationsklassen gelegt. Das ermöglicht beim Bauen des Docker Images, dass die verschiedenen Ordner als Docker Layers hinzugefügt werden, wobei

• tiefere Layers Dateien enthalten sollen, die sich von Build zu Build selten ändern (typisch über Dependency eingebundene 3rd Party Libraries)
• höhere Layers Dateien enthalten, die sich öfters ändern (die Applikationsklassen, an denen entwickelt wird)

Ein korrekt optimiertes Docker Image Layering führt dazu, dass

• Docker Builds schneller rennen, weil unveränderte Layers aus dem Cache wiederverwendet werden
• Docker Pulls (z.B. beim Deployment zu Kubernetes) schneller rennen, wenn gecachete Layers verwendet werden

3) Native Kompilierung durch GraalVM

Ein Aspekt von Quarkus, den Spring derzeit noch nicht anbietet, ist die Möglichkeit, Java Applikationen als nativ ausführbare Programme zu verpacken. Das wird ermöglicht durch die GraalVM und entsprechende C++ Kompilierungs-Tools für die erwünschte Zielplatform (meistens Linux oder Windows Betriebssystem). Das verpackte Native Executable enthält die Java Applikation, mitsamt Libraries und einer reduzierten Virtual Machine.

Es stellt sich die Frage, wofür eine Java Applikation als Native Executable dienen soll, wenn die bisherige Philosophie von Java jene war, dass gebaute Java Binaries durch die JVM auf vielen Platformen gerannt werden können? Das Ziel von Quarkus ist in diesem Fall, dass die Native Executable mit einem „distroless“ Image kombiniert wird, um sehr kleine, schnelle und effiziente Docker Containers zu ermöglichen. „Distroless“ sind solche Linux Images, die keine unnötigen Features (i.e. Package Manager, Bash Tools, JDK/JRE) zum Rennen der Applikation enthalten.

Sofern man mit Docker unterwegs ist, hat das Quarkus Team die native Kompilierung sogar sehr einfach gestaltet, ohne dass man GraalVM oder C++ Tools selbst installieren muss. Der folgende Maven Befehl läuft als Docker Multi-Stage Build ab um automatisch

• ein Linux Image mit GraalVM und C++ Tools zu pullen und darin die Applikation zu bauen
• die gebaute Native Executable mit einem distroless Image zu kombinieren

Vaadin & linkki Integration zu Quarkus

Wer Interesse hat, kann im folgenden GitLab Repository am develop Branch die einzelnen Commits verfolgen, wie Vaadin 8 und linkki Schritt für Schritt in Quarkus integriert wurden. Interessante Code-Stellen wurden mit Kommentaren näher erklärt:

https://gitlab.faktorzehn.at/hpham/linkki-vaadin-quarkus/-/commits/develop

Euer Faktor Zehn-Team