Native image compilation builds Java ahead of time into a platform-specific, self-contained executable. The binary contains the application code, required standard-library classes, language runtime, and statically linked native code, so it runs without a JVM. section 2.4.1 section 1.2.2
The process follows a closed-world assumption: static analysis determines the execution paths needed at runtime. This produces small, fast-starting binaries, commonly starting in tens of milliseconds, but creating them can require configuration and tuning. section 2.4.1 section 1.2.2
Choose the execution format according to the production workload:
- Prefer a native image when startup time matters, such as in serverless environments or other restrictive runtimes. section 1.2.2 section 2.4.1
- Prefer a JVM runnable JAR when the application runs for a long time and sustained throughput matters; JIT optimization can eventually outperform static native optimization. section 2.5.1
- Use Quarkus build-time processing and extensions to reduce the configuration burden, then select native compilation with a build-time switch after development is complete. section 2.5.1 section 1.4
A startup-sensitive service
A Java service deployed to a serverless environment can be compiled into a native executable, avoiding JVM startup and achieving startup times measured in tens of milliseconds. A long-running, throughput-oriented service may instead remain a JVM application so runtime JIT optimization can reach higher peak throughput. section 1.2.2 section 2.5.1
Figure 2.8 A comparison of JVM and native image performance over time. JVM usually outperforms native for long-running processes, but it takes time to reach peak performance.
Compare native-image performance from startup with JVM performance after JIT optimizations reach their peak. section 2.5.1
