Quarkus - Grundlagen & erste Anwendung

Quarkus – Grundlagen & erste Anwendung

0:00 Java hat einen Ruf: mächtig, ausgereift – aber auch schwerfällig beim Start und hungrig auf Arbeitsspeicher. In der Cloud, wo jede Instanz Geld kostet und Sekunden zählen, wird genau das zum Problem. Quarkus tritt an, dieses Bild zu korrigieren: Java, das in Millisekunden startet und mit wenig Speicher auskommt. Heute gehen wir diesen Weg an einem einzigen Tag – vom „Warum überhaupt Quarkus?" bis zum ersten eigenen REST-Service, den Sie selbst zum Laufen bringen.

0:28 Behalten Sie im Kopf: Es geht nicht um ein weiteres Framework zum Auswendiglernen, sondern um eine andere Denkweise, wie moderne Java-Anwendungen entstehen.

Grundlagen & erste Anwendung

0:37 Dieser Tag ist bewusst als durchgehende Linie gebaut: vier Blöcke à 90 Minuten, die aufeinander aufsetzen. Erst klären wir, warum Quarkus überhaupt existiert und wo es sich lohnt. Dann setzen wir ein Projekt auf, lernen die überraschend angenehme Entwickler-Erfahrung kennen – und bauen am Ende einen echten REST-Service.

0:57 Viel davon passiert live, direkt im Editor. Am Abend haben Sie nicht nur zugehört, sondern selbst etwas Lauffähiges gebaut.

Einführung & Kontext

1:05 Beginnen wir mit dem Fundament: Was ist Quarkus eigentlich, und welches Problem löst es? Bevor wir eine einzige Zeile Code schreiben, lohnt es sich zu verstehen, warum dieses Framework so gebaut ist, wie es gebaut ist. Stellen Sie sich zwei Arten vor, ein Möbelstück zu bekommen. Die klassische: Sie erhalten eine Kiste voller Einzelteile und schrauben alles vor Ort zusammen – das dauert.

1:29 Die andere: Das Möbel kommt fertig montiert an. Genau diesen Unterschied macht Quarkus. Klassische Frameworks verdrahten ihre Bausteine erst beim Start der Anwendung. Quarkus erledigt diese Arbeit schon beim Bauen – zur Build-Time. Das Ergebnis ist eine Anwendung, die startklar aus der Kiste kommt: schnell hochgefahren, sparsam im Speicher.

1:50 „Supersonic Subatomic Java" nennen das die Macher augenzwinkernd. Der Leitgedanke dahinter: Container-first – die Anwendung ist von Anfang an für den Container gedacht, nicht für den klassischen Application-Server. Warum dieser Aufwand? Weil sich die Rechnung in der Cloud verschiebt. Früher lief eine Anwendung tagelang auf einem festen Server – ob sie eine Sekunde oder zehn zum Starten braucht, war fast egal.

2:15 Heute skalieren Container horizontal: Bei Lastspitzen kommen im Sekundentakt neue Instanzen dazu, bei Flaute verschwinden sie wieder. Jetzt zählt plötzlich jede Sekunde Startzeit und jedes Megabyte Speicher – denn beides multipliziert sich mit der Zahl der Instanzen und landet direkt auf der Rechnung. Quarkus verlagert die teure Verdrahtungsarbeit in den Build und macht die Laufzeit schlank. Das ist kein Nice-to-have, sondern ein handfester Kostenfaktor.

2:42 Die eigentliche Botschaft dieser Tabelle ist nicht die Zahlenkolonne, sondern eine Entscheidung mit Zielkonflikt. Es gibt nicht den einen besten Modus, sondern drei, die zu unterschiedlichen Situationen passen. Der JVM-Mode ist der solide Standard – gut eine Sekunde Start, völlig ausreichend für Entwicklung und viele klassische Deployments.

3:02 Der Native-Modus mit GraalVM ist der Sprinter: Er startet quasi verzögerungsfrei und braucht minimal Speicher – ideal für Serverless und Scale-to-zero, aber mit längeren Builds erkauft. Das AOT-Caching aus Project Leyden liegt dazwischen und ist noch Technology Preview. Die Kunst ist, den Modus zur Aufgabe zu wählen – nicht reflexhaft zum vermeintlich schnellsten zu greifen.

3:25 Genau hier passiert der häufigste Denkfehler: „Native ist immer besser." Klingt logisch, ist aber falsch. Native-Builds dauern deutlich länger, GraalVM hat seine Eigenheiten mit Reflection und dynamischem Code, und für den Alltag der Entwicklung brauchen Sie das schlicht nicht. Mein Rat: Entwickeln Sie im JVM-Mode, der ist dafür perfekt – und schalten Sie Native erst am Ende ein, wenn es das Einsatzszenario wirklich verlangt.

3:50 Und der zweite Stolperstein für alle, die von Spring kommen: Quarkus ist nicht Spring mit anderen Namen. Die Magie passiert hier zur Build-Time, nicht zur Laufzeit. Dieses Umdenken lohnt sich – erspart aber anfangs Verwirrung. Kurz zur Orientierung, welche Version Sie wählen sollten. Für die Produktion empfiehlt sich die LTS-Linie 3.33 – Long-Term-Support heißt: langfristige Pflege und Sicherheits-Updates, ohne dass Ihnen ständig der Boden unter den Füßen weggezogen wird.

4:20 Wer die neuesten Features braucht, greift zum aktuellsten Release 3.36 – dafür mit kürzerem Support-Fenster. Darunter liegt eine moderne Basis: Java 25, Hibernate ORM 7.2, Jakarta Data. Und das schon erwähnte AOT-Caching aus Project Leyden begleitet uns als Technology Preview – interessant zu beobachten, aber noch nichts für den Produktionsernst.

Setup & Projektstart

4:43 Genug Theorie – jetzt wird es praktisch. Im zweiten Block gehen wir vom leeren Verzeichnis zum lauffähigen Projekt. Sie werden sehen: Der Einstieg ist erstaunlich reibungslos. Ein Quarkus-Projekt ist im Kern ein ganz normaler Maven- oder Gradle-Build – vertrautes Terrain also. Das Besondere steckt in einem Baustein namens Platform-BOM, der `io.quarkus.platform`.

5:06 Denken Sie an einen Dirigenten, der ein Orchester zusammenhält: Jedes Instrument – hier jede Extension – muss zu den anderen passen, sonst klingt es schräg. Die BOM übernimmt genau das. Sie legt fest, welche Versionen aller Bausteine zueinander kompatibel sind, sodass Sie sich nicht mit einem Versions-Puzzle herumschlagen müssen.

5:26 Sie sagen nur, welche Funktionalität Sie wollen – die BOM sorgt dafür, dass am Ende alles harmoniert. Der Gewinn dieses Ansatzes ist vor allem gewonnene Ruhe. Die BOM garantiert kompatible Extension-Versionen – dieses zermürbende „Bibliothek A will Version 2, Bibliothek B nur Version 1" fällt weg. Funktionalität fügen Sie nicht mehr mühsam von Hand zusammen, sondern deklarativ per Extension: Sie sagen, was Sie brauchen, nicht wie es verdrahtet wird.

5:54 Das macht Projekte reproduzierbar – derselbe Generator liefert im ganzen Team dasselbe Ergebnis, kein „bei mir läuft's aber". Und die Einstiegshürde sinkt spürbar, weil CLI und Web-Generator Ihnen die erste, oft abschreckende Konfigurationsarbeit abnehmen. Der rote Faden vom Nichts zum laufenden Projekt ist kurz. Zuerst die Basis: ein JDK 25 und Ihr Build-Tool, dazu das IDE-Plugin – die Werkstatt einrichten.

6:20 Dann installieren Sie die Quarkus-CLI, Ihr zentrales Kommandozeilen-Werkzeug. Damit generieren Sie das Projekt – wahlweise über die CLI oder bequem im Browser auf code.quarkus.io. Beim Generieren wählen Sie gleich die Extensions, die Sie brauchen, etwa `rest` und `rest-jackson`. Zuletzt öffnen Sie das Ergebnis in der IDE und verschaffen sich einen Überblick über die Struktur.

6:44 Ein Ort verdient dabei besondere Aufmerksamkeit: die `application.properties` – dort läuft die zentrale Konfiguration zusammen. Worauf es hier ankommt, ist nicht die exakte Schreibweise, sondern die Idee dahinter: Ein einziger Befehl beschreibt Ihr ganzes Projekt. Sie nennen eine Koordinate – wer sind wir, wie heißt die Anwendung – und listen die gewünschten Extensions auf, hier den REST-Baustein samt JSON-Unterstützung.

7:11 Die CLI legt daraufhin ein vollständiges, lauffähiges Projekt an. Ein Wechsel ins neue Verzeichnis, ein `quarkus dev` – und die Anwendung läuft. Falls Sie die CLI nicht installiert haben: code.quarkus.io erzeugt Ihnen exakt dasselbe Projekt über eine Weboberfläche, wie ein Autokonfigurator, bei dem Sie die Ausstattung anklicken und das fertige Modell herausbekommen.

7:33 Jetzt sind Sie dran. Ihr Ziel: ein Quarkus-Projekt mit passenden Extensions selbstständig generieren und starten. Erfüllt ist die Aufgabe, wenn `quarkus dev` sauber läuft und Sie die Startseite unter localhost:8080 im Browser sehen. Das ist der Moment, in dem aus Folien echtes Handwerk wird – nehmen Sie sich die Zeit, es wirklich selbst zum Laufen zu bringen.

7:54 Wer schneller fertig ist, hat einen Stretch: Fügen Sie dem Projekt nachträglich eine weitere Extension per `quarkus ext add` hinzu und beobachten Sie, wie unkompliziert das geht. Fast alle Startprobleme haben banale Ursachen – deshalb lohnt der Blick darauf. Der Klassiker: die falsche JDK-Version ist aktiv. Installiert heißt nicht aktiv – prüfen Sie mit `java -version`, was wirklich läuft, nicht nur, was auf der Platte liegt.

8:20 Zweitens vertippte Extension-Namen: Ein Buchstabe daneben, und der Baustein wird nicht gefunden – `quarkus ext ls` zeigt die korrekten Namen. Und drittens ein Team-Thema: Wenn die einen Maven, die anderen Gradle nutzen, entsteht schleichend Verwirrung. Legen Sie sich früh auf ein Build-Tool fest, das erspart später viele kleine Reibereien.

Developer Experience

8:42 Kommen wir zu dem Teil, der Quarkus bei vielen Entwicklern so beliebt macht: der Developer Experience. Hier zeigt sich, dass modernes Java-Entwickeln erstaunlich flüssig sein kann. Das Herzstück ist ein einziger Befehl: `quarkus dev`. Er startet Ihre Anwendung in einem besonderen Modus, der drei Dinge mitbringt. Live Reload heißt: Sie ändern Code, speichern, laden die Seite neu – und die Änderung ist da, ohne manuellen Neustart.

9:08 Stellen Sie sich vor, Sie streichen eine Wand und die Farbe ist sofort trocken. Die Dev UI ist eine mitgelieferte Kommandozentrale im Browser für Konfiguration, Extensions und Tests. Und die Dev Services starten Ihnen benötigte Infrastruktur wie eine Datenbank automatisch als Container. Zusammen verwandelt das die Entwicklung von einer Abfolge aus Warten und Neustarten in einen durchgehenden Fluss.

9:32 Warum ist das mehr als nur Komfort? Weil die Länge der Feedback-Schleife darüber entscheidet, wie produktiv – und wie gern – Sie arbeiten. Jeder manuelle Rebuild, jeder Neustart reißt Sie aus dem Gedanken. Live Reload streicht diese Pausen: speichern, neu laden, weiter. Die Dev UI bündelt an einem Ort, wonach Sie sonst an vielen Stellen suchen würden. Und die Dev Services nehmen Ihnen das lästige Aufsetzen von Datenbanken und Co.

9:58 von Hand ab – kein „erst mal die Testumgebung hochziehen". Unterm Strich: eine kürzere Feedback-Schleife bedeutet spürbar produktiveres Arbeiten und deutlich weniger Reibungsverluste im Kopf. So erleben Sie den Dev Mode gleich selbst. Sie starten `quarkus dev` im Projektverzeichnis – und lassen es laufen. Dann öffnen Sie den Endpoint im Browser, ändern eine Kleinigkeit im Code, laden neu und sehen den Effekt sofort.

10:24 Als Nächstes werfen Sie einen Blick in die Dev UI unter `/q/dev-ui`, Ihre zentrale Schaltzentrale. Mit der Taste `r` schalten Sie das Continuous Testing ein – Ihre Tests laufen dann fortlaufend im Hintergrund mit. Und behalten Sie das Log im Auge: Dort sehen Sie, wie die Dev Services im Hintergrund Ihre Container mit Docker oder Podman hochziehen.

10:45 Das Entscheidende an dieser Folie ist nicht der Befehl, sondern was danach passiert: Das Terminal bleibt lebendig. Statt eines starren Prozesses haben Sie eine interaktive Konsole, die auf einzelne Tasten reagiert. Ein `r` stößt Ihre Tests erneut an – Continuous Testing im Wortsinn. Ein `d` öffnet die Dev UI direkt im Browser, ohne dass Sie die Adresse suchen müssen. Und ein `q` beendet alles sauber.

11:09 Merken Sie sich das Prinzip, nicht die einzelnen Tasten: Der Dev Mode ist kein Fire-and-forget, sondern ein Cockpit, das Sie während der Entwicklung ständig bedienen. Jetzt sind Sie dran — und diese Aufgabe ist eine, die man nicht liest, sondern spürt. Es geht darum, die kurze Feedback-Schleife einmal am eigenen Rechner zu erleben: eine Zeile ändern, speichern, im Browser neu laden, und die Änderung ist da.

11:34 Kein Neustart, kein Rebuild, kein Warten. Genau das ist auch das Erfolgskriterium — die Änderung wird ohne Neustart sichtbar, und das Continuous Testing läuft grün mit. Nehmen Sie sich für den zweiten Teil bewusst Zeit: Die Dev UI zeigt Ihnen, welche Extensions im Projekt stecken und was sie konfigurieren. Wer diese Schleife einmal erlebt hat, mag den alten Weg über Bauen und Neustarten nicht mehr.

11:58 Drei Dinge gehen an dieser Stelle erfahrungsgemäß schief. Läuft weder Docker noch Podman, starten die Dev Services nicht — die Datenbank, die Quarkus Ihnen sonst unsichtbar hinstellt, fehlt dann einfach. Ist Port 8080 schon von einem anderen Prozess belegt, kommt die Anwendung gar nicht erst hoch; das passiert öfter, als man denkt, wenn noch eine Instanz aus dem Vormittag läuft.

12:20 Und Live Reload greift nicht bei Konfigurationsfehlern — dann sieht es so aus, als würde sich nichts tun. Der gemeinsame Nenner: Der Dev Mode nimmt Ihnen viel Arbeit ab, aber wenn es klemmt, steht die Ursache im Log. Ein Blick dorthin spart die halbe Fehlersuche.

REST-Grundlagen

12:36 Und nun der Höhepunkt des Tages: Wir bauen den ersten eigenen REST-Service. Alles, was wir bisher aufgebaut haben – Projekt, Extensions, Dev Mode – zahlt jetzt ein. REST ist im Grunde eine simple Idee: Anwendungen sprechen über HTTP miteinander, so wie ein Browser mit einer Webseite. In Quarkus übernimmt das Quarkus REST – früher unter dem Namen RESTEasy Reactive bekannt.

13:00 Und hier zeigt sich die Quarkus-Philosophie besonders schön: Sie beschreiben Ihre HTTP-Endpunkte nicht mit Konfiguration, sondern mit sprechenden Annotationen – kleinen Markierungen am Code, die sagen „das hier ist ein Pfad", „das hier reagiert auf einen Aufruf". Und die JSON-Umwandlung? Erledigt Jackson automatisch im Hintergrund. Aus Ihren Java-Objekten wird JSON und zurück, ohne dass Sie eine Zeile Umwandlungscode schreiben.

13:27 Der Reiz dieses Ansatzes liegt in seiner Selbsterklärbarkeit. Annotationen wie `@Path`, `@GET`, `@POST` lesen sich fast wie ein Satz – jeder im Team versteht auf einen Blick, was ein Endpunkt tut, ganz ohne dickes Konfigurations-Handbuch. Die JSON-Umwandlung passiert automatisch: Sie geben ein Objekt zurück, Jackson macht daraus die passende Antwort.

13:47 Unter der Haube arbeitet ein reaktiver Kern für hohe Effizienz – aber Sie dürfen bequem im vertrauten imperativen Stil schreiben, beide Welten sind möglich. Und das Ganze fügt sich nahtlos in den Dev Mode: Endpunkt ändern, neu laden, per Continuous Testing sofort absichern. Der Weg zum eigenen Endpunkt ist überschaubar. Zuerst stellen Sie sicher, dass die Extension `rest-jackson` im Projekt ist – sie liefert die JSON-Fähigkeit.

14:14 Dann legen Sie eine Resource-Klasse an und markieren sie mit `@Path`, also der Adresse, unter der sie erreichbar ist. Die einzelnen Methoden versehen Sie mit `@GET` oder `@POST` – je nachdem, ob gelesen oder angelegt wird. Als Rückgabetyp verwenden Sie ein schlichtes Datenobjekt, ein DTO; Jackson verwandelt es automatisch in JSON.

14:34 Und testen tun Sie direkt im Dev Mode – im Browser oder mit einem kurzen curl-Aufruf. Fünf Schritte, und der Service steht. Schauen wir nicht auf die Syntax, sondern auf das Muster – denn das wiederholt sich später überall. Die Klasse trägt ihre Adresse als Annotation: Alles, was zu `/kurse` gehört, wohnt hier. Eine Methode ist als Reaktion auf eine Leseanfrage markiert und gibt schlicht eine Liste von Kurs-Objekten zurück.

15:00 Das ist der springende Punkt: Sie geben Java-Objekte zurück – keine handgeschriebenen JSON-Strings, kein Umwandlungs-Code. Den unsichtbaren Rest, das Verwandeln in eine saubere JSON-Antwort, übernimmt Jackson im Hintergrund. So wenig Code für einen vollwertigen HTTP-Endpunkt – genau diese Knappheit ist der eigentliche Gewinn.

15:20 Zeit für Ihr Meisterstück des Tages: Ihr Ziel ist ein eigener REST-Endpunkt, der JSON ausliefert – entworfen und selbst implementiert. Geschafft haben Sie es, wenn ein Aufruf von `GET /kurse` eine JSON-Liste mit dem Status 200 zurückgibt, geprüft im Browser oder per curl. Das ist der Moment, in dem alles zusammenkommt – Projekt, Dev Mode, REST. Genießen Sie ihn.

15:43 Und wer noch Luft hat, nimmt den Stretch: Ergänzen Sie einen `@POST`-Endpunkt zum Anlegen neuer Kurse. Damit haben Sie beide Richtungen abgedeckt – Lesen und Schreiben. Drei kleine Fallen kosten hier erfahrungsgemäß die meiste Zeit – gut, sie vorher zu kennen. Erstens die zwei Ebenen von `@Path`: Die Annotation auf der Klasse legt den Grundpfad fest, die auf der Methode ergänzt ihn – wer beide verwechselt, wundert sich über 404.

16:10 Zweitens die fehlende `rest-jackson`-Extension: Ohne sie gibt es keine automatische JSON-Umwandlung, und die Antwort bleibt rätselhaft. Und drittens die stille Falle: Fehlen Ihrem Datenobjekt Getter und Setter – oder machen Sie es einfach zum Record – bleibt das JSON leer. Jackson braucht einen Weg, an die Werte zu kommen. Drei kleine Checks, viel gespartes Grübeln.

Danke & nächste Schritte

16:32 Damit schließt sich der Kreis: An einem Tag vom „Warum Quarkus?" bis zum eigenen REST-Service – Sie haben nicht nur zugehört, sondern selbst gebaut. Alle Materialien finden Sie in der Freigabe zum Nacharbeiten. Und die Reise geht weiter: Das nächste Seminar vertieft Dependency Injection, Persistenz, Konfiguration und Tests – also genau die Bausteine, mit denen aus dem ersten Service eine echte Anwendung wird.

16:58 Bei Fragen erreichen Sie uns unter info@HCO.de. Vielen Dank für Ihre Aufmerksamkeit und das Mitmachen – und viel Freude beim Weiterbauen mit Quarkus.