How to Turn a Java Hello World into a Fast Native Binary with GraalVM

Write a simple Java program and compile it with javac, then run it with java.

public class Hello {
    public static void main(String[] args) {
        System.out.println("hello world");
    }
}

Running the program requires a JRE.

Instead, use GraalVM's native-image tool to compile the program into a native executable.

native-image Hello

After compilation, a binary file hello appears, which can be executed directly without a JRE.

./hello
hello world

This demonstrates that native-image turns Java code into a JVM‑independent native binary.

GraalVM offers three main features:

New JIT technology for faster Java execution.

Polyglot language support.

Building JVM‑independent native images.

Using native-image reduces startup time dramatically but increases binary size. A comparison of Hello.class (415 B, 0.12 s) and the native hello (10 M, 0.01 s) shows the trade‑off.

For larger applications such as Spring Boot, native images can be built with Spring Native support. After generating a project from start.spring.io, the Maven command mvn package -Pnative produces a native executable.

# native image build output (truncated)
[INFO] Executing: ...native-image -cp ... -H:Name=demo-1
... (build logs) ...

Running the traditional JAR takes about 2 seconds to start, while the native executable starts in 0.078 seconds.

Native compilation has limitations: it does not support dynamic class loading, reflection, serialization, JNI, etc., unless explicit configuration is provided. These constraints stem from the AOT (ahead‑of‑time) compilation model, which assumes a closed world at build time.

Spring Native mitigates this by supplying the necessary configuration for common frameworks, allowing developers to build fast‑starting native Spring Boot applications.

Overall, GraalVM native-image can dramatically improve startup latency, especially for cloud‑native workloads, though binary size and configuration complexity must be considered.