Seminar Micronaut – AOT, GraalVM und Native Images

Kurze Startzeiten und ein geringer Speicherbedarf entstehen nicht automatisch durch einen nativen Build. Das Seminar verbindet Micronaut AOT, GraalVM Native Image, Build-Konfiguration und Laufzeitanalyse zu einem reproduzierbaren Verfahren für produktionsfähige Anwendungen.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• AOT-Optimierungen und Native-Image-Kompilierung fachlich und technisch unterscheiden
• Reflexion, Proxys, Ressourcen und dynamische Klassenladevorgänge beherrschbar machen
• Native Anwendungen reproduzierbar bauen, testen, paketieren und diagnostizieren
• Startzeit, Speicher, Durchsatz und Build-Aufwand anhand belastbarer Messungen bewerten

Zielgruppe

Erfahrene Java- und Kotlin-Entwickler, Modernisierungsteams, Softwarearchitekten und technische Leads.

Voraussetzungen

Gute JVM-Entwicklungskenntnisse, Micronaut-Grundlagen und Erfahrung mit HTTP, Tests sowie Build- und Deploymentprozessen.

Seminarinhalte

1. Schritt 1: Ausgangsanwendung und Messbasis vorbereiten

   Eine bestehende HTTP-Anwendung wird reproduzierbar gebaut. Startzeit, Speicherverbrauch, Artefaktgröße und ausgewählte Antwortzeiten werden als Vergleichsbasis erfasst.

2. Schritt 2: AOT-Verarbeitung einordnen

   Build-Zeit-Analyse, generierte Metadaten, optimierte Konfiguration und die Abgrenzung zur Laufzeitreflexion werden untersucht. Aktivierte Optimierungen werden transparent dokumentiert.

3. Schritt 3: Native-Build-Werkzeugkette einrichten

   GraalVM, Build-Plugins, Toolchains und erforderliche Systembibliotheken werden kontrolliert konfiguriert. Lokale und containerisierte Build-Wege werden verglichen.

4. Schritt 4: Reflexion und dynamisches Verhalten prüfen

   Serialisierung, Bean-Erzeugung, Proxys, Service Loader, Ressourcen und Bibliotheken mit dynamischem Verhalten werden identifiziert. Notwendige Metadaten werden gezielt ergänzt.

5. Schritt 5: Native Image erzeugen und verifizieren

   Ein erstes natives Artefakt wird gebaut, gestartet und mit funktionalen Smoke-Tests geprüft. Build-Protokolle und Analyseausgaben werden systematisch ausgewertet.

6. Schritt 6: Fehler im nativen Lauf diagnostizieren

   Fehlende Klassen, Ressourcen, Initialisierungsprobleme und Plattformabweichungen werden reproduziert. Ursachen werden über minimale Testfälle statt über pauschale Freigaben eingegrenzt.

7. Schritt 7: Tests in die Build-Kette integrieren

   Unit-, Integrations- und native Tests werden getrennt organisiert. Zeitintensive Prüfungen erhalten eindeutige Auslöser und Abbruchkriterien für die CI-Pipeline.

8. Schritt 8: Container und Betriebsparameter erstellen

   Schlanke Images, nicht privilegierte Benutzer, Health-Prüfungen, Speichergrenzen und Startparameter werden für das native Artefakt festgelegt.

9. Schritt 9: JVM- und Native-Variante bewerten

   Startzeit, Speicher, Durchsatz, Diagnosefähigkeit, Build-Dauer und Bibliothekskompatibilität werden gegenübergestellt. Daraus entsteht eine belastbare Entscheidungsmatrix.

Praxisübungen

• Native Build einer REST-Anwendung mit Datenzugriff
• Behebung eines Reflexions- und Ressourcenfehlers
• Vergleichsmessung zwischen JVM-, AOT- und Native-Ausführung
• CI-Prüfkette mit Smoke-Test und Containerstart

Methodik

Kurze fachliche Einordnungen wechseln mit Demonstrationen und schrittweisen Übungen. Jeder Arbeitsstand wird gebaut, ausgeführt und durch automatisierte oder betriebliche Prüfungen abgesichert. Fehlerfälle werden bewusst einbezogen, damit Diagnose und Wiederanlauf nicht erst im Produktivbetrieb entstehen.