Quarkus

Quarkus
Basisdaten
Entwickler	Red Hat
Aktuelle Version	3.32.4 (19. März 2026)
Programmier­sprache	Java
Kategorie	Java Technologie
Lizenz	Apache License 2.0
https://quarkus.io/

Quarkus ist ein von Red Hat entwickeltes, full-stack, Kubernetes-natives Java-Framework, zugeschnitten auf die Nutzung mit GraalVM. Im Vergleich zu anderen Frameworks, wie beispielsweise Spring, bietet es einen geringen Speicherverbrauch und eine geringe Startzeit.

Zusätzlich ermöglicht Quarkus Features wie Ahead-of-Time-Kompilierung, Hot Reload und reaktives SQL und unterstützt Dependency Injection. Dabei gibt es unterschiedliche Arten des Deployment beispielsweise über Maven und Docker.

Quarkus wurde von den Red Hat Entwicklern erstmals am 7. März 2019 als „supersonic, subatomic“ Framework vorgestellt.^[1][2] Dieser Vergleich zur Quantenmechanik soll auf die Eigenschaften des Frameworks verweisen. Dabei steht das supersonic für die Geschwindigkeit und das subatomic für den geringen Speicherplatzbedarf.^{[3.1][4.1][5.1]}

Quarkus wurde entwickelt, um den hohen Arbeitsspeicherbedarf von Java zu verringern und die Startzeit zu verbessern. Grund hierfür ist, dass Java für den Anwendungsfall Cloud und die Programmieridee Microservices angepasst werden soll. Dabei werden sowohl neue Features zur Verfügung gestellt, als auch die bisherigen APIs (Application Interfaces) weiterhin unterstützt, darunter Java EE, Eclipse Vert.x und Spring.^[5.2]

Java unterstützt nativ die sogenannte Just-in-Time (JIT) Kompilierung. Diese erzeugt für Teile des Programmcodes, welche sehr oft ausgeführt werden, Assembler-Code. Das Prinzip der Ahead-of-Time-Kompilierung von Quarkus baut darauf auf und kompiliert direkt alle .java-Dateien zu Assembler-Code. Dieser Code kann dann auch zu einer betriebssystemabhängigen, ausführbaren Datei kompiliert werden. Jedoch dauert die AOT‑Kompilierung deutlich länger als der Standardweg, bei dem zunächst .class‑Dateien mit Java‑Bytecode erzeugt werden.^[3.2]

Quarkus unterstützt einen Hot Reload unabhängig von der genutzten Entwicklungsumgebung. Das heißt, dass Code, der während der Laufzeit geändert wird, direkt nachgeladen werden kann. Die Auswirkungen sind somit sogleich sichtbar. Zudem werden auch Abhängigkeiten nachgeladen.^[3.3] Um den Hot Reload zu nutzen, muss man die Anwendung im „development mode“^[6] starten.^[4.2][7]

Das Design von Quarkus führt zur Kompatibilität mit Kubernetes. Die Kompatibilität mit Kubernetes ermöglicht kleinere Deployment-Einheiten, geringeren RAM-Bedarf und kürzere Startzeiten. Das ist im Hinblick auf die Nutzung von Containern wichtig.^[3.4] Um dies zu erreichen, implementiert Quarkus die MicroProfile-Spezifikation.^[5.1] Daraus folgt ein reduzierter Arbeitsspeicherbedarf, schnellere Startzeit und weniger Betriebssystem-Threads. Zudem werden Container-Health-Checks (d. h. automatische Überprüfung ob der Container erreichbar ist), Unterstützung von CNCF(Cloud-Native Computing Foundation) Projekte und die Kubernetes-API direkt in Quarkus zur Verfügung gestellt.^[5.3]

Die Dependency Injection(DI) wird genutzt, um Java-Objekte in einem bestimmten Kontext bekannt zu machen. Die entsprechenden Annotationen sorgen dafür, dass die Objekte korrekt instanziiert und auch wieder gelöscht werden. Dabei unterstützt Quarkus Contexts and Dependency Injection(CDI) und die DI vom Spring Framework.^[3.5]

Dabei ist ArC die Implementierung der CDI von den Red Hat Entwicklern, welches für Quarkus entwickelt wurde. Während ArC zwar die meisten Punkte der Spezifikation implementiert, gibt es ein paar spezifische Sachen, die nicht funktionieren. Beispielsweise gibt es keine CDI-Decorator.^[3.6]

Neben der imperativen Programmierung unterstützt Quarkus auch Programmieransätze zur reaktiven Programmierung.^[6]

Ergänzend zu der reaktiven Unterstützung die Core Java bietet, stellt Quarkus noch „Reaktives SQL“ zur Verfügung. Das ermöglicht die Ergebnisse einer SQL Abfrage eventbezogen zu verarbeiten, während gleichzeitig eine publish-subscribe Beziehung zwischen dem Backend und der Datenbank besteht. Das heißt, es gibt eine asynchrone Ergebnis-Benachrichtigung an den Subscriber.^[8] Zusätzlich können Ergebnisse der Query direkt als Stream behandelt werden, statt die Ergebnisse in einer Schleife zu durchlaufen. Allerdings werden nur MySQL, DB2 und PostgreSQL unterstützt.^[3.7]

Um reaktive Nachrichten zu benutzen, wird von Quarkus die Microprofile Spezifikation für reaktive Streams implementiert. Dabei besteht ein reaktiver Stream aus Publisher, Subscriber und Processor. Weiterhin wird ein reaktive Stream immer von dem Publisher gestartet, durchläuft mehrere Processing-Schritte und wird dann vom Subscriber empfangen. Dabei können die reaktiven Nachrichten in Quarkus sowohl in grundlegendem Quarkus, als auch mit Apache Kafka genutzt werden.^[5.4][6]

Quarkus kann nicht nur in Java genutzt werden, sondern auch in Kotlin und Scala, da beide Sprachen auch die JVM (Java Virtual Machine) nutzen.^[3.8] Dabei gibt es für Kotlin ein entsprechendes Plugin.^[9]

Für Microsoft Visual Studio Code^[4.3] und für IntelliJ gibt es ein Quarkus-Plugin. Dabei bieten sowohl das VS-Code-Plugin, als auch das IntelliJ-Plugin, einen eigenen Wizard für das Einbinden von Quarkus Extensions, Debugging Unterstützung und verschiedene autovervollständigungs Funktionen.^[10] Zu beachten ist, dass das Plugin für Visual Studio Code die Java Extensions aus dem Java Extension Pack benötigt.^[11] Für Eclipse ist die Quarkus Unterstützung Teil der JBoss Tools.^[12][13] Die Entwicklungsumgebung NetBeans wird nicht unterstützt.^[3.9]

Es gibt verschiedene Wege Quarkus zu deployen. Es reicht ein JDK 11+, man kann aber auch Maven oder Gradle benutzen. Diese Ansätze werden in Quarkus Terminologie als „JVM Mode“ bezeichnet, weil die Anwendung in der JVM läuft.^[4.4] Dabei benutzt Quarkus HotSpot als JVM.^[14] Allerdings kann auch mit der Graal VM ein betriebsystemspezifische, native Anwendung erstellt werden. Jeder dieser Ansätze kann in einem Container laufen, beispielsweise in Docker oder mit Kubernetes.^[3.10]

Quarkus unterstützt den Build‑Prozess über ein eigenes Maven‑Plugin. Standardmäßig erzeugt Quarkus dabei kein sogenanntes Uber‑JAR, das alle Abhängigkeiten in einer einzelnen Datei bündelt. Diese Option kann jedoch über die Konfiguration der Anwendung aktiviert werden.^[4.5]

Neben Maven unterstützt Quarkus auch Gradle als Build‑Werkzeug. Die Gradle‑Integration basiert dabei auf dem Quarkus-Maven‑Plugin.^[4.6] Die Integration erfolgt über das Quarkus‑Plugin, das die für den Build‑Prozess erforderlichen Einstellungen bereitstellt.^[14]

Quarkus benutzt die Graal VM, um ein „native Executable“ also eine betriebssystemspezifische Anwendung zu bauen.^[6][7] Das ist die Hauptidee, da sich diese native Anwendung, aufgrund des geringeren Arbeitspeicherverbrauchs und der schnelleren Startzeit,^[5.5] für die Anwendung im Container oder im serverless Kontext eignet. Serverless meint dabei eine Anwendung ohne eigene Serververwaltung.^[15] Um diese Datei zu erzeugen, wird ein entsprechendes Maven Profil genutzt.^[4.6]

Beim Erstellen von einem Quarkus Projekt werden automatisch Dockerdateien erzeugt. Eine für den JVM Mode und eine weitere für die Option der nativen Anwendung. Das Dockerfile für den JVM Mode integriert dabei die JAR und alle Abhängigkeiten in den Container und öffnet einen Port für JMX (Java Management Extension).^[4.7]

Um ein natives Image für einen Docker Container zu erzeugen, kann nicht direkt der Graal VM Ansatz verwendet werden, da dieser für das Betriebssystem des ausführenden Rechners die native Anwendung erstellt. Stattdessen kann mit Maven ein entsprechendes Image erzeugt werden, welches in einem Docker Container laufen kann.^[4.8]

Für den Einsatz in Kubernetes werden Quarkus‑Anwendungen in Container‑Images verpackt, die in einem Kubernetes‑Pod ausgeführt werden. Die Erstellung dieser Images kann über Jib, Docker oder S2I erfolgen.^[5.6] Jede dieser Strategien bietet die Möglichkeit, die Build-Parameter zu verändern, um das Image zu beeinflussen. Im Folgenden werden die Strategien JIB und S2L^[4.9] kurz erläutert. Wie man ein Docker-Image mit Quarkus baut, ist im Docker Abschnitt erklärt.^[4.10]

JIB bietet die Möglichkeit Docker oder Oracle-Cloud-Interface-Container ohne eine Docker Daemon zu bauen. Das wird auch als Dockerless bezeichnet. Dadurch wird der Build-Prozess beschleunigt und das Ergebnis bezüglich des Speicherbedarfs kleiner.^[4.9]

Bei dem Source-to-Image-Ansatz wird mit einer BuildConfig und zwei ImageStreams gearbeitet. Beide können von der Quarkus Kubernetes Extension erzeugt werden. Dabei basiert der S2I Ansatz auf der Red Hat Container Plattform OpenShift.^[4.9]

Viele Spring Annotationen können auch in einem Quarkus Projekt verwendet werden. Diese werden dann von Quarkus und ArC umgesetzt. Jedoch ist der Spring Unterstützung nicht vollständig, so gibt es beispielsweise keinen Spring Application Context.^[3.11] Die Absicht der Red Hat Entwickler ist dabei nicht Spring Software zu Quarkus Projekten zu migrieren, sondern Spring Entwicklern einen einfacheren Einstieg in Quarkus zu ermöglichen.^[5.7]

(Quelle: ^[3.11][5.7])

• Spring Core
• Spring Web
• Spring Security
• Spring Data JPA
• Spring Boot Properties
• Spring Dependency Injection^[4.11]
• Spring Cache API
• Spring DI API
• Spring Scheduled

Im technischen Vergleich zu Spring verlagert Quarkus einen größeren Teil der Arbeit in den Build-Prozess, was dazu führt, dass entsprechend weniger Verarbeitung beim Starten der Anwendung passieren muss.^[5.8][14]

Einige Artikel empfehlen, Quarkus für neue Projekte zu nutzen, wenn bereits Java‑EE‑Erfahrung im Team vorhanden ist, raten jedoch davon ab, bestehende Spring‑Projekte umzuschreiben.^{[16][17][5.7]}

Eingesetzt wird Quarkus vor allem im Bereich der Container- und Cloudumgebungen.^[14] Aufgrund der Verbreitung arbeitet Red Hat weiterhin aktiv an dem Projekt, bringt monatlich ein neues Feature heraus und behebt Fehler. (Stand November 2025)^[18]

• Guide To Quarkus - von Baeldung
• Build Your First Application - von Quarkus

• Red Hat Guides

• Quarkus in Action
• Quarkus for Spring Developers