W-JAX 2026: Wie kann ich Java schneller starten — und wann lohnt sich das?

Zusammenfassung

Ein schnellerer Java-Start kann sich lohnen, wenn Sie:

• Serverless Computing nutzen (etwa Amazon Lambda),
• viele Server betreiben oder
• eine sehr hohe Verfügbarkeit anstreben.

Java by Design: mehr Zeit, mehr CPU, mehr Speicher.

Schneller starten lässt sich Java mit:

• Spring Boot Tuning
• Class Data Sharing (CDS) & OpenJDK Project Leyden
• OpenJDK Project CRaC
• GraalVM Native Image

Wie ich zu diesem Ergebnis komme, steht in meinen Folien.

Zusätzliche Informationen zu den Folien stehen weiter unten.

Organisatorisches

Ort

Ich halte den Vortrag auf der W-JAX 2026 im Westin Grand München.

Vortrag

Mein Vortrag ist am Mittwoch, 4. November 2026, von 18:15 bis 19:15 Uhr.

Abstract

So können Java-Anwendungen schneller starten – sortiert nach aufsteigendem Geschwindigkeitsgewinn: Framework-Tuning (ab Spring Boot 3), Class Data Sharing (CDS, ab Java 17), Project Leyden (ab Java 24), CRaC (ab Java 17) und GraalVM Native Image (ab Java 17). Aber: Je schneller der Start, desto größer sind Aufwand und Beschränkungen. Das kann sich lohnen, wenn man Serverless Computing nutzt, viele Server betreibt oder besonders hohe Verfügbarkeit der Anwendung garantieren muss.

Der Vortrag demonstriert mit detaillierten Benchmarks eines Spring-Boot-Beispiel-Projekts alle Optionen und erklärt deren Vor- und Nachteile.

Der Vortrag enthält eine Demo.

Was macht mich zum Experten?

Im Frühjahr 2022 habe ich eine sehr erfolgreiche sechsteilige Artikelserie über natives Java auf InfoQ betreut. Seitdem habe ich mehrere Artikel über Project Leyden, CRaC und GraalVM Native Image geschrieben und auch Vorträge darüber gehalten.

Benchmark-Repo

Nutzung

Das Repo ist ein Fork der offiziellen Spring Petclinic. Ich habe Shell-Skripte für den Build des Projekts (compile-and-run.sh) sowie für die Trainings- und Benchmark-Läufe (benchmark.sh) ergänzt, eine kleine Bibliothek für CRaC hinzugefügt und einige Dateien ignoriert. Die Skripte sind nur unter Linux und macOS getestet.

Sie können die sechs Benchmarks selbst mit ./compile-and-run.sh [szenario] ausführen, wobei szenario eines der folgenden ist:

• baseline — das Basisszenario mit reinem Spring Boot, Option 0 in meinem Vortrag. Braucht JDK 25.
• tuning — Spring Boot Tuning, Option 1 in meinem Vortrag. Braucht JDK 25.
• cds — Class Data Sharing, Teil von Option 2 in meinem Vortrag. Braucht JDK 25.
• leyden — Project Leyden, Teil von Option 2 in meinem Vortrag. Braucht JDK 25.
• crac — Project CRaC, Option 3 in meinem Vortrag. Braucht das JDK 25 von Azul mit CRaC-Unterstützung und läuft nur unter Linux.
• graalvm — GraalVM Native Image, Option 4 in meinem Vortrag. Braucht das GraalVM Oracle JDK 25 und sehr viel Speicher — 16 GB reichten nicht.

Startup-Zeit und Speicherverbrauch messen

Das Benchmark-Skript führt drei Warmup-Läufe und danach sieben Benchmark-Läufe durch. Es verwirft den schnellsten und den langsamsten Benchmark-Lauf und bildet dann den Mittelwert der übrigen fünf.

Die Startup-Zeit wird auf zwei Arten gemessen:

• Bei CRaC sucht das Skript im Spring-Boot-Log nach dem Text restored JVM running for X ms.
• Bei allen anderen Szenarien sucht es nach Started PetClinicApplication in X.XXX seconds.

Den Speicherverbrauch misst das Skript, indem es die Anwendung über /usr/bin/time startet und den Speicher aus der Ausgabe liest:

• macOS: nutzt peak memory footprint aus /usr/bin/time -l
• Linux: nutzt Maximum resident set size aus /usr/bin/time -v

Das Skript rechnet einheitlich in KB, gibt die Werte aber in MB aus.

Hinweise

• Ich habe diese Skripte mit der KI-IDE Cursor erstellt und danach mit Claude Code überarbeitet. Das erklärt vielleicht manche Merkwürdigkeit im Skript.
• Ursprünglich wollte ich auch Maven-Build-Befehle einbauen. Das Gerüst steht noch drin, funktioniert aber überhaupt nicht.

Weitere Informationen zum Vortrag

Einleitung

Hier ist die sechsteilige Artikelserie über natives Java auf InfoQ aus dem Jahr 2022. Ich war nicht der Autor, sondern habe sie betreut. Die Artikel und Nachrichten, die ich selbst geschrieben habe, stehen hier.

Lohnt sich das?

Informationen

• AWS Lambda SnapStart ist hier beschrieben.
• Ein Beispiel dafür, dass Java teurer ist, ist Apples Migration zu Swift für Teile seines Passwortsystems.

• Die originale Java-Beschreibung steht in einem InfoQ-Artikel zum 30. Geburtstag von Java.

ROI-Beispiel

Das Szenario: Eine Microservice-Anwendung in Java auf Kubernetes soll ihre Betriebskosten senken. Der Ansatz: Umstieg auf GraalVM Native Image für die Kompilierung, um den Speicherverbrauch zu senken. Dadurch passen mehr Pods auf einen Kubernetes-Node, und es werden weniger Server benötigt.

Die Annahmen:

• Das Projekt läuft auf Kubernetes unter Linux auf Amazon-EC2-T3.2XLarge-Servern (32 GB RAM, 8 CPUs). Ein solcher Server kostet 280 Euro pro Monat, also 10.080 Euro über 36 Monate.
• Die Entwickler arbeiten unter macOS und debuggen Produktionsanwendungen in einem Linux-Container.
• Ein Entwickler / Admin kostet 100 Euro pro Stunde.
• Die Investition muss nach drei Jahren einen positiven Return on Investment (ROI) haben.

Die Personalkosten:

• Einmalige Einführung (Build & Deployment umstellen, Entwickler-Training): 120 Stunden = 12.000 Euro
• Monatliche Wartung: 4 Stunden × 30 Monate = 120 Stunden = 12.000 Euro
• Upgrades alle sechs Monate (Spring Boot, GraalVM): 16 Stunden × 5 = 80 Stunden = 8.000 Euro
• Produktivitätsverlust (Produktions-Troubleshooting mit nativ kompilierten Programmen): 4 Stunden × 35 Monate = 140 Stunden = 14.000 Euro
• Personalkosten über drei Jahre insgesamt: 46.000 Euro

Die Betriebskosten:

• Amazon EC2 T3.2XLarge als zusätzlicher Build-Server (32 GB RAM, 8 CPUs): 10.080 Euro

Die Gesamtkosten betragen 46.000 Euro Personal plus 10.080 Euro Betrieb, also insgesamt 56.080 Euro.

Für einen positiven ROI muss GraalVM Native Image die Zahl der Amazon-EC2-T3.2XLarge-Server im Kubernetes-Cluster um mindestens sechs senken. Das senkt die Kosten um 10.080 Euro × 6 = 60.480 Euro und spart über drei Jahre 4.400 Euro.

Wie schneller?

Spring Boot Tuning

• Spring AOT ist hier dokumentiert, die JAR-Extraktion hier. Dieser Baeldung-Artikel beschreibt beides.
• Hier einige Spring-Tickets zu Problemen mit AOT und Native Image (inzwischen alle geschlossen): eins, zwei und drei.

Class Data Sharing & Project Leyden

• Spring beschreibt Class Data Sharing und den AOT-Cache hier.
• Das ist die Homepage von Project Leyden. Und hier ist mein Artikel zur Auslieferung in JDK 24.
• Das sind die JEPs von Project Leyden: JEP 483, JEP 514, JEP 515, JEP 516 und JEP 544 für JDK 28.

Project CRaC

• Das ist die Homepage von Project CRaC.
• Hier spricht Brian Goetz, Java Language Architect bei Oracle, über CRaC.
• Das ist Azuls OpenJDK mit CRaC-Unterstützung, und hier ist Bellsofts Liberica JDK mit CRaC-Unterstützung.
• Mit diesen Releases haben große Java-Frameworks CRaC-Unterstützung bekommen: Spring Boot 3.2, Quarkus 2.10.0, Micronaut 3.7 und Helidon 4.2.

GraalVM Native Image

• Das ist die GraalVM-Dokumentation zu Native Image. Und hier die Spring-Boot-Dokumentation dazu.
• Java-Frameworks wie Spring Boot liefern die Native-Image-Konfiguration für ihre Bibliotheken wie Spring Security oder Spring Data in der Regel mit.
• Das GraalVM Reachability Metadata Repository enthält die Native-Image-Konfiguration für verbreitete Java-Bibliotheken. Native Image nutzt es automatisch.
• Diese Features sind mit GraalVM Native Image unmöglich:
  • neue Klassen und Methoden zur Laufzeit erzeugen,
  • neuen Bytecode ausführen,
  • eher exotische Classloader-Features und
  • Java Agents (etwa für Observability).
• Diese Features funktionieren nur teilweise:
  • AWT und JavaFX (nicht unter macOS),
  • JMX,
  • viele Datenpunkte des Java Flight Recorder und
  • einige Test-Frameworks.
• Diese Features erfordern Konfiguration:
  • Reflection und
  • explizites Klassen-Laden.

Folien