Quarkus

Quarkus – Grundlagen

0:00 Java hat einen Ruf, der ihm lange anhing: großartig für den Server, aber schwerfällig beim Start und hungrig auf Arbeitsspeicher. In einer Welt, in der Anwendungen in Containern laufen und im Minutentakt hoch- und wieder heruntergefahren werden, ist das kein Schönheitsfehler mehr, sondern eine Rechnung, die jeden Monat kommt.

0:18 Genau hier setzt Quarkus an. In diesem ersten Modul legen wir das Fundament: Was das Framework anders macht, wie es Ihre Objekte verwaltet, wie ein Projekt entsteht und wie Sie es konfigurieren, ohne den Code anzufassen. Am Ende haben Sie eine kleine Anwendung, die läuft — und verstehen, warum sie so schnell startet. Kurz zum Handwerkszeug, damit Sie mitarbeiten können.

0:40 Ein JDK ab Version 17 ist das Minimum, das Quarkus verlangt — wir arbeiten hier mit Java 25, und Sie sehen gleich, warum das nichts kostet. Maven ab Version 3.9 brauchen Sie ohnehin, wobei die mitgelieferten mvnw-Skripte reichen, wenn Sie nichts installieren wollen. Der einzige Punkt, der überrascht: eine laufende Container-Runtime, also Docker oder Podman.

1:02 Nicht, weil wir gleich in Container deployen, sondern weil Quarkus sich Datenbank und Message-Broker während der Entwicklung selbst besorgt. Dazu später mehr — merken Sie sich für heute nur: die Runtime muss laufen, mehr nicht.

Das Framework

1:17 Bevor wir eine einzige Zeile Code schreiben, klären wir die Ausgangsfrage: Was unterscheidet Quarkus eigentlich von dem, was Sie kennen? Die Antwort ist erstaunlich konkret und hängt an einer einzigen Design-Entscheidung — an der Frage nämlich, wann die Arbeit passiert. Wer die verstanden hat, versteht auch, warum an so vielen anderen Stellen dieses Frameworks Dinge einfacher sind, als man es gewohnt ist.

1:39 Also schauen wir uns zuerst das Fundament an, und danach wird der Rest fast von selbst plausibel. Stellen Sie sich zwei Umzugsfirmen vor. Die eine packt erst am Zieltag aus und überlegt vor Ort, wo alles hinkommt. Die andere hat schon in der Werkstatt jeden Karton beschriftet und den Plan gezeichnet — am Zieltag wird nur noch abgestellt.

1:59 Klassische Java-Frameworks arbeiten wie die erste Firma: Sie verdrahten beim Start, durchsuchen Klassen, werten Annotationen aus. Quarkus arbeitet wie die zweite und verschiebt diese Arbeit in den Build. Das ist der Kern von "Container-first": Nicht der Applikationsserver ist das Ziel, sondern das fertige Container-Image.

2:18 Dazu kommt ein Anspruch, den das Projekt selbst "Developer Joy" nennt — und der ist mehr als ein Marketingwort, wie Sie gleich sehen werden. Was bringt das konkret? Zunächst Geld. Eine Anwendung, die in Millisekunden statt in Sekunden startet und ein Vielfaches weniger Speicher belegt, kostet in der Cloud schlicht weniger — und sie skaliert dort, wo eine träge Anwendung schon abgehängt ist.

2:41 Der zweite Gewinn ist technischer Natur: Weil Quarkus auf Reflection weitgehend verzichtet, weiß es zur Build-Zeit, was die Anwendung tut. Das spart nicht nur Rechenzeit, es ist auch die Voraussetzung dafür, mit GraalVM ein natives Image zu bauen. Ob Sie das brauchen, ist eine andere Frage — aber die Tür steht offen, und das ist bei klassischen Frameworks nicht selbstverständlich.

3:04 Drei Missverständnisse begegnen einem immer wieder. Erstens: "Container-first" heißt nicht "nur Container". Ihre Anwendung läuft genauso auf einer normalen JVM auf einem normalen Server — der Container ist die Optimierungsrichtung, nicht die Bedingung. Zweitens: GraalVM klingt nach einer Hürde, ist aber keine. Sie brauchen es nur, wenn Sie ein natives Image bauen, und dann meist im Build-System, nicht auf Ihrem Rechner.

3:30 Lokal genügt ein gewöhnliches JDK. Und drittens: Quarkus zwingt Sie nicht in ein Programmiermodell. Imperativ, reaktiv, event-getrieben, serverlos — das ist ein Kontinuum, auf dem Sie sich bewusst positionieren dürfen. Ein Punkt, den man beim ersten Projekt gern übersieht, aber später teuer bezahlt: die Versionswahl. Quarkus veröffentlicht sehr regelmäßig — alle paar Wochen eine neue reguläre Version mit neuen Funktionen.

3:57 Daneben gibt es LTS-Linien, die über einen längeren Zeitraum nur noch Fehlerbehebungen bekommen, keine neuen Features. Für ein Produktivsystem ist das fast immer die richtige Wahl, weil Sie Sicherheitsupdates bekommen, ohne bei jedem Sprung Ihre Anwendung nachziehen zu müssen. Wir arbeiten in diesem Seminar auf der aktuellen LTS. Wenn Sie in Ihrem Projekt Neues ausprobieren wollen, nehmen Sie die reguläre Linie — nur eben bewusst und nicht aus Versehen.

ArC & CDI

4:24 Kommen wir zu dem Mechanismus, der im Hintergrund fast jede Zeile Ihres Codes berührt, ohne dass Sie ihn je direkt aufrufen: die Verwaltung Ihrer Objekte. Wenn Sie aus dem Spring-Umfeld kommen, ist Ihnen das Prinzip vertraut, und Sie werden vieles wiedererkennen. Wenn nicht, ist dies der wichtigste Abschnitt des Moduls — denn ohne dieses Konzept wirkt der Code, den wir gleich schreiben, wie Zauberei.

4:46 Und Zauberei ist genau das, was man in einer Anwendung nicht haben will. Die Idee lässt sich mit einem Restaurant erklären. Sie kochen nicht selbst und kaufen auch nicht ein — Sie bestellen, und das fertige Gericht kommt an den Tisch. Genauso sagt eine Komponente in Ihrer Anwendung nur, was sie braucht, und der Container liefert das passende Objekt fertig zusammengebaut.

5:07 Dieser Container heißt in Quarkus ArC und setzt den Java-Standard CDI um. Der entscheidende Unterschied zu dem, was Sie vielleicht kennen: ArC baut den Abhängigkeitsgraphen schon beim Kompilieren. Was zur Laufzeit passiert, ist nur noch das Ausliefern. Deshalb startet die Anwendung so schnell — und deshalb merkt Quarkus einen Verdrahtungsfehler beim Bauen, nicht erst im Betrieb.

5:30 Man muss diese vier Phasen nicht auswendig können, aber es lohnt sich zu verstehen, was da abläuft — spätestens wenn eine Fehlermeldung auftaucht. Zuerst richtet sich der Container ein und legt die Kontexte an, in denen Ihre Objekte später leben. Dann sucht er die Beans und ordnet sie zu einem Graphen, der auch die Reihenfolge festlegt.

5:50 Anschließend dürfen Extensions eigene Komponenten beisteuern, die gar nicht aus einer Ihrer Klassen stammen. Und ganz am Ende wird geprüft. Fehlt eine Abhängigkeit, bricht der Vorgang sofort ab — mit einer Meldung, die Ihnen sagt, wer was vermisst. Dieses "fail-fast" ist gewollt: lieber jetzt als um drei Uhr nachts. Ein Punkt, der Umsteiger aus dem Jakarta-EE-Umfeld erwischt: CDI Portable Extensions unterstützt ArC nicht direkt.

6:16 Das ist kein Versehen, sondern die Konsequenz aus der Build-Zeit-Verdrahtung — eine Erweiterung, die zur Laufzeit den Container umbaut, passt schlicht nicht ins Bild. Der übliche Weg führt über eigene Beans, die Sie an den Application-Kontext binden und dann injizieren. In der Praxis trifft das die wenigsten. Und behalten Sie im Kopf: Der Kern der Sache bleibt die Bean, und eine Bean ist erst einmal ein ganz normales Java-Objekt.

6:41 Auch Producer-Methoden und -Felder gehören zur Spezifikation — Sie verlieren also nichts an Ausdruckskraft.

Projekt starten

6:48 Genug Theorie. Legen wir ein Projekt an. Das klingt nach einem Schritt, über den man nicht reden muss, aber es gibt zwei Wege dorthin, und sie eignen sich für unterschiedliche Situationen. Wir schauen uns beide an und ich sage Ihnen, welchen ich im Alltag nehme und warum. Danach starten wir die Anwendung zum ersten Mal — und dabei begegnet Ihnen die Eigenschaft von Quarkus, die man am schwersten in Worte fassen und am schnellsten vermissen kann.

7:13 Es gibt zwei Wege, und sie führen zum selben Ergebnis. Der eine ist die Quarkus CLI: ein Kommandozeilenwerkzeug, das Sie einmal installieren und danach nie wieder suchen müssen. Ein Befehl, Projekt steht. Der andere ist code.quarkus.io — eine Website, die wie ein Autokonfigurator funktioniert: Sie klicken zusammen, was Sie brauchen, und laden ein ZIP herunter.

7:36 Für den Einstieg ist die Website anschaulicher, weil Sie sehen, welche Erweiterungen es überhaupt gibt. Im Alltag gewinnt die CLI, weil sie den Umweg über den Browser spart. Wichtig in beiden Fällen: Prüfen Sie hinterher die Java-Version in der pom.xml — sie ist schnell übersehen und später ärgerlich. Zwei Befehle, und das war es. Interessant ist der zweite: der Entwicklungsmodus. Was dort passiert, ist der erwähnte "Developer Joy" in Aktion.

8:04 Sie ändern eine Klasse, speichern, laden die Seite neu — und die Änderung ist da. Kein Neustart, kein Neubauen, kein Warten. Wer aus der Java-Welt kommt, unterschätzt anfangs, wie sehr das den Arbeitsrhythmus verändert; man probiert plötzlich Dinge aus, für die man sich vorher zu schade war. Dazu kommt die Dev UI unter der Adresse, die Ihnen der Start anzeigt: eine Oberfläche, in der Sie Konfiguration und Erweiterungen einsehen können.

8:31 Wenn Sie die CLI nicht installiert haben, tut es das mitgelieferte Maven-Skript genauso.

Konfiguration

8:37 Kommen wir zu einem Thema, das unspektakulär klingt und trotzdem darüber entscheidet, ob eine Anwendung in der Cloud brauchbar ist: Woher kommen eigentlich die Werte, mit denen sie arbeitet? Datenbankadresse, Zugangsdaten, Zeitlimits — alles, was sich zwischen Ihrem Rechner und dem Produktivsystem unterscheidet. Wer das falsch löst, merkt es nicht sofort, sondern erst beim ersten Deployment, und dann ist es teuer. Wer es richtig löst, denkt nie wieder darüber nach.

9:05 Denken Sie an die Schalter an einem Gerät. Sie bauen kein neues Radio, wenn Sie den Sender wechseln wollen — Sie drehen am Knopf. Externalisierte Konfiguration ist genau das: Alles, was sich zwischen Entwicklungsrechner, Testsystem und Produktion unterscheidet, steht außerhalb des Codes und wird beim Start hineingereicht.

9:24 Datenbankadresse, Zugangsdaten, Zeitlimits, Schalter für Funktionen. Das klingt selbstverständlich, ist es aber nicht: Sobald ein einziger Wert fest im Code steht, brauchen Sie für jede Umgebung ein eigenes Artefakt — und damit ist das Versprechen dahin, dass genau das getestete Paket auch in Produktion läuft. Für cloud-native Anwendungen ist dieser Punkt nicht verhandelbar.

9:46 Wenn ein Wert an mehreren Stellen steht, muss klar sein, wer gewinnt. Das Prinzip dahinter ist einfacher, als die Tabelle aussehen lässt: Je näher eine Quelle am konkreten Start der Anwendung liegt, desto stärker ist sie. Was Sie beim Aufruf mitgeben, schlägt eine Umgebungsvariable; die schlägt die Datei im Projekt; und die schlägt den Standardwert, den eine Erweiterung mitbringt.

10:08 Praktisch heißt das: Sinnvolle Voreinstellungen gehören ins Projekt, Umgebungsspezifisches kommt von außen — und wenn Sie im Betrieb schnell etwas überschreiben müssen, geht das, ohne irgendetwas neu zu bauen. Der einzige Wert, den keine Quelle mehr überschreibt, ist der fest verdrahtete im Code. Genau deshalb wollen wir ihn vermeiden.

10:28 Worauf es hier ankommt, sind nicht die Annotationen, sondern der Standardwert. Ein Property ohne Fallback ist eine Zeitbombe: Fehlt der Wert in einer Umgebung, merken Sie es beim Start — oder schlimmer, erst beim ersten Aufruf. Mit einem Default verhält sich die Anwendung stattdessen vorhersehbar und läuft weiter. Das ist keine Bequemlichkeit, sondern eine Entscheidung über Robustheit.

10:51 Und noch eine Kleinigkeit, die auffällt: Das Feld ist nicht als private deklariert. Das ist bei CDI so vorgesehen und kein Versehen — der Container kommt so ohne Umweg an das Feld heran. Jetzt wird es praktisch. Mit einem vorangestellten Profilnamen halten Sie Entwicklung, Test und Produktion in einer einzigen Datei auseinander — dieselbe Eigenschaft, drei Werte, und Quarkus greift den passenden.

11:15 Die drei Standardprofile sind eingebaut, eigene wie "staging" dürfen Sie erfinden. Darüber hinaus können Sie Werte ineinander verschachteln und aus mehreren Eigenschaften zusammensetzen. Das ist mächtig — und genau deshalb ein Rat: sparsam einsetzen. Eine Konfiguration, die man rückwärts auflösen muss wie ein Rätsel, hat ihren Zweck verfehlt. Der Wert soll ablesbar sein, nicht errechenbar.

Injection

11:39 Zeit, die beiden letzten Themen zusammenzuführen. Wir bauen jetzt eine eigene Klasse, lassen sie einen Konfigurationswert ziehen und geben sie dem Container zur Verwaltung. Das Beispiel ist bewusst winzig — es geht nicht darum, etwas Nützliches zu programmieren, sondern darum, das Muster einmal vollständig zu sehen. Denn dieses Muster wiederholt sich in jeder Klasse, die Sie in Quarkus schreiben werden, von der kleinsten Hilfsklasse bis zum größten Dienst.

12:06 Der Ablauf ist bewusst klein gehalten, weil es hier um das Muster geht, nicht um die Funktion. Eine Klasse wird mit einer Annotation als verwaltete Bean markiert, zieht einen Konfigurationswert und stellt eine Methode bereit. Der eigentlich lehrreiche Schritt ist der letzte. Sie könnten die Abhängigkeit direkt in ein Feld injizieren lassen — es funktioniert, und viele machen es so.

12:27 Der Weg über den Konstruktor ist trotzdem der bessere: Er macht sichtbar, was die Klasse zum Leben braucht, und er erlaubt Ihnen, im Test einfach ein anderes Objekt hineinzureichen. Eine Klasse, die sich nicht testen lässt, weil ihre Abhängigkeiten unerreichbar sind, ist ein selbstgemachtes Problem. Was Sie hier sehen, ist die kleinste vollständige Einheit des Systems: eine Klasse, die dem Container gehört, einen konfigurierten Wert kennt und etwas damit tut.

12:54 Mehr ist eine Bean nicht. Der Punkt, auf den es ankommt: Nirgendwo in Ihrem Code steht ein "new". Sie erzeugen das Objekt nicht, Sie bekommen es — fertig gebaut, mit allem, was es braucht. Das wirkt bei einer einzelnen Klasse wie Aufwand ohne Gegenwert. Bei dreißig Klassen, die einander kennen, ist es der Unterschied zwischen einer wartbaren Anwendung und einem Knäuel.

13:17 Jetzt sind Sie dran. Die Aufgabe ist absichtlich eine, die jeder kennt — damit Sie sich nicht mit der Logik aufhalten, sondern mit dem, worum es geht: Konfiguration. Vier Werte, alle injiziert, alle mit Standardwerten abgesichert, und einer davon aus zwei anderen zusammengesetzt. Der Reiz liegt in der Probe aufs Exempel: Überschreiben Sie den Zählwert beim Start und schauen Sie, ob die Anwendung folgt.

13:40 Kommentieren Sie einen Wert aus und prüfen Sie, ob der Standard greift. Wenn beides funktioniert, haben Sie verstanden, wie Konfiguration in Quarkus arbeitet — und das ist deutlich mehr wert als das Ergebnis auf der Konsole.

Lösung – FizzBuzz

13:53 Schauen wir uns eine mögliche Lösung an. Ich sage bewusst "eine mögliche" — es gibt mehrere Wege, und Ihrer darf anders aussehen. Interessanter als der Code ist ohnehin die eine Stelle, an der sich fast jeder einmal vertut, und sie hat nichts mit Quarkus zu tun, sondern mit einer Denkgewohnheit. Wenn Sie die kennen, ersparen Sie sich diesen Fehler auch an ganz anderen Stellen — wir werden ihm in Modul drei nämlich wiederbegegnen.

14:19 Der Aufbau folgt genau dem, was wir besprochen haben: vier Eigenschaften, eine davon zusammengesetzt, eine verwaltete Klasse, und der Aufruf aus der Anwendung heraus. Die eine Stelle, an der es klemmt, ist die Reihenfolge der Prüfungen. Wer zuerst auf Teilbarkeit durch drei prüft, kommt bei der Fünfzehn nie zum kombinierten Fall — die Bedingung hat schon zugeschlagen.

14:39 Das ist kein Quarkus-Thema, sondern ein klassischer Denkfehler, und er zeigt ganz nebenbei etwas Wichtiges: Der spezifischere Fall gehört nach oben. Diese Regel werden Sie beim Schneiden von Endpunkten in Modul drei wiedersehen. Der Code selbst ist unspektakulär, und das ist Absicht. Interessant ist, was nicht darin steht: kein Lesen einer Datei, kein Auswerten von Kommandozeilenargumenten, keine Prüfung, ob ein Wert überhaupt da ist.

15:05 All das hat der Container erledigt, bevor die Methode das erste Mal läuft. Die Klasse kennt nur noch ihre vier Felder und die Aufgabe, die sie damit erfüllen soll. Genau diese Trennung ist der Gewinn: Fachlogik hier, Herkunft der Werte dort. Wenn morgen die Konfiguration aus einem Secret-Store statt aus einer Datei kommt, ändert sich an dieser Klasse nichts.

Fragen?

15:27 Halten wir fest, was Sie mitnehmen. Der Container verwaltet Ihre Objekte — Sie beschreiben Abhängigkeiten, statt sie zu erzeugen, und bekommen sie fertig geliefert. Konfiguration gehört nach außen, mit vernünftigen Standardwerten abgesichert und über Profile je Umgebung getrennt. Und Quarkus verlagert, wo es geht, Arbeit in den Build, weshalb die Anwendung so schnell startet und Fehler früh auffallen.

15:50 Im nächsten Modul wird es konkreter: Wir holen echte Daten aus einer Datenbank — und Sie werden sehen, dass Quarkus Ihnen dabei sogar die Datenbank selbst abnimmt.