GraalVM Native Image converts Java applications into native executable files through AOT compilation, solving the problems of slow startup and high memory usage in the traditional JVM mode. 1. The startup speed is milliseconds, suitable for Serverless and microservices; 2. The memory usage is reduced by 30% to 70%; 3. The deployment package is smaller and there is no need to carry JVM; 4. The security is improved and the attack surface is reduced. Note when using: 1. Reflection, dynamic proxy, etc. need to be explicitly configured; 2. Resource files need to be included through resource-config.json; 3. Dynamic class loading is limited; 4. Some libraries that rely on ASM or dynamically generate bytecode are incompatible. Mainstream frameworks such as Spring Boot 3, Quarkus, and Micronaut are well supported and are suitable for cold boot-sensitive scenarios and are an important operating mode of Java in modern cloud native environments.

Java has long been known for being "written once, run everywhere", thanks to the JVM's instant compilation (JIT) and cross-platform bytecode execution. However, as the requirements for startup speed, memory footprint and cloud-native deployment efficiency become increasingly high, the traditional JVM model has begun to appear "cumbersome". GraalVM's Native Image technology is designed to solve these problems - it allows you to compile Java applications in advance (Ahead-of-Time, AOT) as a local executable.

What is Native Image?

Native Image is a tool provided by GraalVM that can directly compile Java bytecode (.class files or JARs) into platform-specific native executable files (such as ELF on Linux, Mach-O on macOS, PE on Windows). This process occurs before the application runs, that is, AOT compilation.

Unlike traditional JVM startup process:

• Traditional JVM : Java → Bytecode → JVM Explanation JIT Compilation → Machine Code (Runtime)
• Native Image : Java → Bytecode → Native Image Compilation → Native executable file (start, machine code)

The result is a separate binary file that no longer relies on JVM, starts very fast and has a lower memory footprint.

Why use Native Image?

1. Extremely fast startup speed

Native mirror startup time is usually in the millisecond level , which is especially suitable for cold start-sensitive scenarios such as Serverless (such as AWS Lambda), microservices, CLI tools, etc.

For example: It originally took 3 to 5 seconds to start a Spring Boot application, but it may only take 50ms after using Native Image.

2. Lower memory usage

Without the runtime overhead of JVM, off-heap memory is more controllable. Native mirrors usually use 30% to 70% less memory than equivalent JVM applications.

3. Smaller deployment packages

Although the generated binary files may be larger than JAR, they do not need to package the JVM , and the overall container image size is smaller, suitable for lightweight deployments.

4. Safer (some extent)

Without JVM, the attack surface is reduced; and the code has been determined at compile time, and dynamic behaviors such as reflection are limited, which helps with security auditing.

How to use Native Image?

Prerequisites

• Install GraalVM (recommended to use graalvm-ce or graalvm-ee )
• Install native-image tool (via gu install native-image )

 # Example: JDK using GraalVM
export JAVA_HOME=/path/to/graalvm
gu install native-image

Compile a simple Java application

 // HelloWorld.java
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, Native World!");
    }
}

Compilation steps:

 javac HelloWorld.java
native-image HelloWorld

Generate helloworld executable file and run it directly:

 ./helloworld
# Output: Hello, Native World!

Notes and restrictions

Native Image is not omnipotent. It has some key limitations, mainly due to the nature of AOT compilation:

1. Reflection, dynamic proxy, and JNI need to be explicitly configured

AOT cannot predict which classes will be used reflected when compiling, so the compiler must be told through the configuration file.

Common ways:

• Annotation with @RegisterForReflection
• Provide reflect-config.json file

 // reflect-config.json
[
  {
    "name": "com.example.MyClass",
    "methods": [
      { "name": "<init>", "parameterTypes": [] }
    ]
  }
]

2. The resource file must be explicitly included

Configuration files, templates, international resources, etc. will not be automatically packaged and must be specified through resource-config.json .

3. Dynamic class loading is limited

Class.forName() , ClassLoader dynamic loading classes are not available at runtime (unless known at compile time).

4. Some libraries are incompatible

For example: Groovy, JRuby, some frameworks that use ASM to generate bytecode dynamically, may have errors in Native Image.

Integration with mainstream frameworks

Fortunately, many modern Java frameworks already support Native Image:

• Spring Boot : Supported through Spring Native project (now integrated into Spring Boot 3)
• Quarkus : The default priority is to support native compilation, known as "born for cloud native"
• Micronaut : handles a lot of logic at compile time, naturally suitable for AOT

For example: To create a native application using Quarkus, just:

 mvn quarkus:build -Dquarkus.package.type=native

---

Summarize

GraalVM Native Image allows Java applications to get rid of the "burden" of JVM and brings a qualitative leap in startup speed, memory efficiency and lightweight deployment. Although it has limitations on reflex and dynamic characteristics, these pain points are being gradually addressed as the ecosystem matures (especially the support of Spring Boot 3 Quarkus Micronaut).

If your application is:

• Microservice or Serverless function
• CLI Tools
• Scenarios that are sensitive to cold start

Then, it's worth trying Native Image. It is not about replacing the JVM, but provides Java with another operating mode that is more suitable for modern cloud environments .

Basically that's it - AOT compilation is no longer the "future", it has already started running in production.

The above is the detailed content of GraalVM Native Image: Compiling Your Java Application Ahead-of-Time. For more information, please follow other related articles on the PHP Chinese website!