Nov 2, 2025 | updated Nov 4, 2025 | 7 min read
Share: Twitter LinkedIn Bluesky Threads Mastodon Email Copy
Part 16 of 16 in the Talks series.
talk jfs graalvm spring-boot crac leyden

atra.consulting: "Wie kann ich Java schneller starten – und wann lohnt sich das?"

atra.consulting logo

Summary

Starting Java faster could be worthwhile when you:

  • use serverless computing (like Amazon Lambdy),
  • run many serviers, or
  • aim for very high availability.

By design, Java users more time, more CPU, and more memory.

We can get Java to start faster with:

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

Please see my slides for why I came to this conclusion.

Additional information about the slides is below.

Logistics

Location

I will give the talk at the main office of my employer, atra.consulting, in Stuttgart.

Talk

My talk will be on November 4, 2025, at 15:00.

Abstract

German

So können Java-Anwendungen schneller starten – sortiert nach aufsteigendem Geschwindigkeitsgewinn: Framework-Tuning, Class Data Sharing (CDS), Project Leyden/JEP 483 (ab Java 24), CRaC und GraalVM Native Image. Aber: Je schneller der Start, desto größer sind Aufwand und Beschränkungen. Das kann sich lohnen, weil die Uptime der Anwendung steigt, die Anzahl der Standby-Instanzen sinkt oder Serverless Computing billiger wird.

Der Vortrag demonstriert mit einem Spring-Boot-Beispiel-Projekt alle Optionen, erklärt Vor- und Nachteile und gibt Hinweise für die Wirtschaftlichkeitsberechnung.

English

This is how Java applications can start faster – sorted by ascending speed gains: Framework tuning, Class Data Sharing (CDS), Project Leyden/JEP 483 (from Java 24 onward), CRaC, and GraalVM Native Image. However: The faster the startup, the greater the effort and limitations. This can be worthwhile because application uptime increases, the number of standby instances decreases, or serverless computing becomes cheaper.

The talk demonstrates all options using a Spring Boot example project, explains pros and cons, and provides guidance for cost-benefit calculations.

Who Made Me the Expert?

In the spring of 2022, I was the editor of a highly popular, six-part article series about native Java on InfoQ. I wrote several articles about Project Leyden, CRaC, and GraalVM Native Image and gave talks about them, too.

Slides

Here are the slides as PDF. They have more content and more text than my talking slides. They are just 0.4 MB:

You can also get the slides in their original Keynote format. “Keynote” is Apple’s presentation application. Why would you do that? My slides have less text than the PDF version, so you can see what I cut. I also animated the slides, so they are more pleasant to watch. Or maybe you want to peek under the hood to see how I achieved specific effects. The slides also have fewer words than the PDF ones - it’s a talk, not a read! But they do have speaker notes. These slides are 6 MB.

Benchmark Repo

Usage

The repo is a fork of the official Spring Petclinic. I added the shell scripts for building the project (compile-and-run.sh) and for the training and benchmark runs (benchmark.sh), added a small library for CRaC, and ignored some of the files. The scripts are only tested for Linux and macOS!

You can run the six benchmarks yourself with ./compile-and-run.sh [scenario], where scenario is one of these:

  • baseline: The baseline scenario of plain Spring Boot – option 0 in my talk. Needs JDK 25.
  • tuning: Spring Boot tuning – option 1 in my talk. Needs JDK 25.
  • cds: Class Data Sharing – part of option 2 in my talk. Needs JDK 25.
  • leyden: Project Leyden – part of option 2 in my talk. Needs JDK 25.
  • crac: Project CraC - option 3 in my talk. Needs JDK 25 from Azul with CRaC support and only works in Linux.
  • graalvm: GraalVM Native Image – option 4 in my talk. Needs GraalVM Oracle JDK 25 and a lot of memory – 16 GB weren’t enough.

Measuring Startup Time and Memory

The benchmark script performs three warmup runs, then seven benchmark runs. It discards the fastest and slowest benchmark run and then takes the average of the remaining five runs.

Startup time is measured in two ways:

  • For CRaC, the script looks for the text restored JVM running for X ms in the Spring Boot log.
  • For all other scenarios, it looks for Started PetClinicApplication in X.XXX seconds.

Memory consumption is measured with running the benchmarked application through /usr/bin/time and then reading the memory from the output:

  • macOS: Uses peak memory footprint from /usr/bin/time -l
  • Linux: Uses Maximum resident set size from /usr/bin/time -v.

The script converts to KB for consistency, but displays in MB for output.

Notes

  • I created these scripts with the AI IDE Cursor. Then I updated it with Claude Code. This may account for some weirdness you see in the script.
  • I originally wanted to include Maven build commands. The skeleton’s still in there, but it does not work at all.

Additional Talk Information

Intro

Here is the six-part article series about native Java on InfoQ from 2022. I wasn’t the author, I was the editor. The articles and news items I wrote are here.

Section “Lohnt sich das?” (“Is it worth it”?)

Information

Sample Return on Investment Calculation

The scenario is that a microservice Java application on Kubernetes wants to reduce operational costs. The approach is to switch to GraalVM Native Image for compilation and reduce memory consumption. This will lead to more pods fitting on a Kubernetes node, reducing the servers needed.

Here are the assumnptions:

  • The project runs on Kubernets in Linux on Amazon EC2 T3.2XLarge servers (32 GB RAM, 8 CPUs). That server costs 280 Euro per month, which means 10,0080 Euro over 36 months.
  • Developers work on macOS and debug production applications inside a Linux container.
  • A developer / admin has costs of 100 Euro/hour.
  • The investment has to have a positive Return on Investment (ROI) after three years.

Here are the labor costs:

  • One-time Introduction (changing build & deployment, training developers): 120 hours = 12,000 Euro
  • Monthly maintenance: 4 hours x 30 months = 120 hours = 12,000 Euro
  • Upgrades every six months (Spring Boot, GraalVM): 16 hours x 5 = 80 hours = 8,000 Euro
  • Loss of productivity (debugging native executables for production problems): 4 hours x 35 months = 140 hours = 14,000 Euro
  • Total labor cost over three years: 46,000 Euro

Here are the operational costs:

  • Amazon EC2 T3.2XLarge as additional build server (32 GB RAM, 8 CPUs): 10,0080 Euro

The total cost is 46,000 Euro for labor plus 10,0080 Euro for operations, for a grand total cost of 56,080.

In order to have a positive ROI, using GraalVM Native Image needs to reduce the number Amazon EC2 T3.2XLarge servers in Kubernetes by at least six, which would reduce costs by 10,080 Euro x 6 = 60,480 Euro. That saves 4,480 Euro over three years.

Section “Wie schneller?” (“How faster?”)

Spring Boot Tuning

Class Data Sharing & Project Leyden

Project CRaC

GraalVM Native Image

  • This is the GraalVM documentation of Native Image. And here’s the Spring Boot documentation for it.
  • Java frameworks like Spring Boot typically ship with the Native Image configuration information for their libraries, like Spring Security or Spring Data.
  • The GraalVM Reachability Metadata Repository contains the Native Image configuration for popular Java libraries. Native Image uses it automatically.
  • These are features that are impossible with GraalVM Native Image:
    • to create new classes and methods at runtime,
    • to execute new bytecode.
    • rather exotic classloader features, and
    • Java Agents (used for observability, for instance).
  • Here are features that only work partially:
    • AWT and JavaFY (not on macOS),
    • JMX,
    • many Java Flight Recorder datapoints, and
    • some testing frameworks.
  • These features require configuraiton:
    • reflection, and
    • explicit class loading,