GraalVM Native Image is a technology for compiling Java applications into native executables. 1. Fast startup and low memory footprint through AOT compilation; 2. Manually configure reflection, dynamic proxy and resources to avoid runtime errors; 3. Suitable for microservices, Serverless and CLI tools, but not suitable for scenarios where frequent dynamic loading of classes or rapid iterative development; 4. It is recommended to use frameworks such as Quarkus and Micronaut to simplify configuration; 5. It must be fully tested to ensure compatibility, so although it is not a universal alternative, it can significantly improve performance and resource efficiency in cloud-native scenarios.

Java Native Image with GraalVM is a way to compile Java applications ahead-of-time (AOT) into standalone native executes that start instantly and use fewer resources. It's not traditional Java execution — instead of running on the JVM with JIT compilation, your app becomes a self-contained binary.

Here's what you need to know to understand and use GraalVM Native Image effectively.

What Is Native Image?

Native Image is a technology from GraalVM that compiles Java bytecode ( .class files) directly into a native machine executable — no JVM needed at runtime.

Instead of:

 Java App → JVM → JIT Compilation → Execution

You get:

 Java App → Native Image (AOT) → Native Binary → Direct Execution

This means:

• Faster startup — no JVM warm-up or class loading delay.
• Lower memory usage — no JIT compiler, GC overhead is reduced.
• Smaller footprint — ideal for containers and serverless environments.

But: you lose some dynamic features (like reflection, class loading at runtime) unless explicitly configured.

How Does It Work?

Native Image performs static analysis of your application at build time to determine:

• Which classes and methods are used
• What reflection is needed
• Which resources to include

Then it:

1. Strips away unused code (like tree-shaking in JavaScript)
2. Converts the remaining bytecode into native machine code
3. Embeds a minimum runtime (including garbage collector)

The result is a single binary you can run like:

 ./my-app

No java -jar , no JVM arguments, no classpath.

When Should You Use It?

? Good for:

• Microservices (fast startup = better scaling)
• Serverless functions (AWS Lambda, Google Cloud Functions)
• CLI tools (near-instant response)
• Environments with limited memory

? Not ideal for:

• Apps that heavily use dynamic class loading
• Applications relying on deep reflection (unless configured properly)
• Rapid development cycles (build time is slow — 5–10 minutes common)

Basic Usage Example

1. Install GraalVM and enable Native Image:

    # Using SDKMAN (Linux/macOS)
   sdk install java 21.0.2-graal
   gu install native-image

2. Write a simple Java app:

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

3. Compile and build native image:

    javac HelloWorld.java
   native-image HelloWorld

4. Run it:

    ./helloworld # No JVM needed

Handling Reflection, Proxies, and Resources

Native Image doesn't automatically detect:

• Reflection ( Class.forName , Method.invoke )
• Dynamic proxies
• JNI
• Resources (files in src/main/resources )

You must tell it what to include via:

• reflect-config.json — list classes used via reflection
• proxy-config.json — for dynamic proxies
• resource-config.json — to include specific files

Or use the @RegisterForReflection annotation (in Quarkus or Micronaut):

 @RegisterForReflection
public class MyModel { ... }

Alternatively, run your app with -Dnative-image.enable-reachable-types=true or use trace configuration via the --initialize-at-build-time and agent:

 # Run with agent to generate config
java -agentlib:native-image-agent=config-output-dir=src/main/resources/META-INF/native-image HelloWorld

Then rebuild — the agent records what your app uses dynamically and generates config files automatically.

Build-Time vs. Run-Time Initialization

By default, classes are initialized at run time . But you can reduce startup time by initializing some at build time :

 --initialize-at-build-time=com.mypackage.OptimizedAtBuildTime

?? Only safe for classes without side effects or external dependencies (like network, files).

Performance Trade-offs

So: great for cold starts, less ideal for long-running apps needing peak performance.

Frameworks That Support Native Image

Some frameworks are optimized for it:

• Quarkus — designed for native from the start
• Micronaut — minimal reflection, build-time injection
• Spring Native — experimental support in Spring Boot

These handle most configuration automatically.

Common Pitfalls

• Missing reflection config → ClassNotFoundException at runtime
• Dynamic resource loading → files not included
• Using System.getProperty() in static init → returns null if property not set at build time
• Too much build-time init → breaks if code depends on runtime environment

Always test your native binary thoroughly.

Summary

GraalVM Native Image turns Java apps into fast, lightweight executables — perfect for cloud-native use cases. It requires careful configuration, especially around reflection and dynamic features, but frameworks like Quarkus make it much easier.

It's not a drop-in replacement for all Java apps, but when used right, it delivers dramatic improvements in startup and footprint.

Basically: if you're building microservices or serverless functions, it's worth trying. Just don't expect it to work perfectly out of the box.

The above is the detailed content of Java Native Image with GraalVM Explained. For more information, please follow other related articles on the PHP Chinese website!