Native Image eliminates every phase of JVM startup that takes time. There is no JVM process to launch because the output is a native ELF/PE/Mach-O executable. There are no classes to load because every class the application ever uses is compiled and linked at build time. There is no interpreter because all bytecode is precompiled to native machine code. There is no JIT warmup because all optimization decisions are made at build time. The only remaining work is starting the Substrate VM runtime — a minimal threading and GC system — and jumping to the main method. This takes milliseconds instead of the seconds a JVM needs for its initialization phases.

Native Image requires that all code reachable at runtime be determinable at build time. Starting from the main entry point, the static analyzer traces through every method call, field access, and type reference it can find. Any code not reachable through this trace is excluded from the final image. This enables aggressive optimizations — dead code elimination, aggressive inlining, removal of dynamic dispatch — but it means features that work at runtime in a JVM (dynamic class loading, runtime bytecode generation, reflection on unknown types) require explicit configuration or become unavailable. The closed-world assumption is what makes AOT compilation possible and what makes Native Image different from a traditional JVM.

The JIT compiler in a JVM has a crucial advantage over AOT compilation: it observes actual runtime behavior. It sees the real types flowing through a call site, which branch is taken most often, which methods are in the real hot path, and what the actual array lengths and object graphs look like. With this information, the JIT makes speculative optimizations that are only valid for the observed behavior. AOT compilation cannot make these speculative bets because it does not know the runtime profile. Additionally, JIT compilers can deoptimize and recompile when assumptions are violated, while Native Image cannot. For long-running applications that warm up to a stable profile, JIT's runtime-informed optimizations typically produce faster code than AOT's conservative compile-time optimizations.

Reflection in Native Image requires upfront configuration because the static analyzer cannot discover which types will be reflected upon at runtime. You provide this configuration through JSON files — primarily reflect-config.json for Class.getDeclaredField and similar APIs, resource-config.json for resources accessed via getResourceAsStream, and proxy-config.json for dynamic proxy interfaces. The easiest approach is to run the native-image agent (-agentlib:native-image-agent) during testing — it observes reflection, resource, and proxy usage and automatically generates the configuration files. After generating the configuration, you rebuild the native image with those files included. Without this configuration, reflection on types not known at build time silently returns null or throws exceptions at runtime.

The Substrate VM is the minimal runtime that Native Image links into every native executable. It replaces the traditional JVM runtime components with lightweight alternatives. The key differences: the Substrate VM has no JIT compiler (all compilation is AOT), no bytecode interpreter, no class loader (all classes are linked at build time), and a simple single-threaded GC instead of advanced collectors like G1 or ZGC. It does provide thread management, stack management, and implementations of reflection, native libraries, and other runtime features — but implemented in a way that is compatible with static analysis and closed-world compilation. The result is a runtime that starts instantly and uses minimal memory, at the cost of flexibility and advanced GC optimizations.

The Substrate VM uses a simple single-threaded garbage collector optimized for short-lived processes rather than the advanced multi-threaded collectors (G1, ZGC, Shenandoah) used in production JVMs. The Substrate GC is not incremental and does not have concurrent marking phases — it stops the world and collects everything in one pause. For short-lived workloads (serverless functions, CLI tools), this is acceptable because heap sizes are small and GC pauses are measured in milliseconds. For long-running services with large heaps, the simple collector would cause unacceptable stop-the-world pauses. The tradeoff reflects the Substrate VM's design goal: minimize startup latency and memory footprint for short-lived processes, not maximize throughput for sustained workloads. If you need better GC behavior in Native Image, you can configure the build to use a different GC algorithm, but this increases image size and initialization time.

The static analysis phase, also called points-to analysis, starts from the application entry point and recursively traces all reachable code — methods, fields, types, resources. It builds a complete graph of everything the application needs at runtime. The analysis can fail or be incomplete for several reasons: reflection on types not known at build time produces no trace (the class is not included), dynamic proxy generation creates types not visible to static analysis, bytecode instrumentation libraries add code at runtime that the analyzer cannot see, and JNI calls to native libraries require manual configuration since the analyzer cannot trace native code. When the analyzer misses code, the resulting image silently fails at runtime — a method call throws a confusing exception or a reflected field returns null. Using the native-image agent during testing is the standard way to discover and fix these gaps before deployment.

Native Image runs all static initializers and static field initializers at build time rather than runtime. This means if a static field reads an environment variable, a system property, or any runtime-only value, that value is captured and frozen into the image heap at build time. When the image runs in a different environment (different DATABASE_URL, different JVM options), it still uses the values from build time — causing failures that are difficult to diagnose because the symptom appears at runtime as if the wrong environment variable were set. The solution is to avoid reading environment-specific values in static initializers, and to defer initialization to runtime using annotations like @InjectRuntimeInitialization or by restructuring code to read configuration at startup rather than in static blocks. This is a fundamental difference from traditional JVM behavior that surprises developers who move existing applications to Native Image.

JIT compilation occurs at runtime and observes actual execution behavior — which types flow through call sites, which branches are taken, what the working set looks like. This runtime data enables speculative optimizations that AOT cannot perform: the JIT assumes the observed behavior will continue and generates faster code for the common case. AOT compilation happens at build time with no runtime data — it must make conservative decisions that work for all cases, not optimized decisions for the observed case. This is why JIT-compiled code typically runs faster for long-running workloads: the JIT can specialize for the actual workload. AOT's advantage is startup: all compilation is done before the application runs, so there is no JIT warmup period. For short-lived processes, AOT wins because the startup savings outweigh the peak performance loss. For long-running servers that warm up to stable hot paths, JIT typically produces 10-30% higher throughput.

The native-image agent (-agentlib:native-image-agent) is a JVM agent that intercepts reflection calls, resource access, and proxy usage during test execution. As your application runs through its normal usage patterns, the agent records everything it sees and writes the corresponding JSON configuration files: reflect-config.json, resource-config.json, and proxy-config.json. The agent must be active during representative test runs — if you miss a code path in testing, its reflection usage will not be in the generated configuration. For web applications, this means running integration tests that exercise the API endpoints. For libraries, unit tests may not cover all reflection usage at runtime. The generated configuration is a starting point; you may need to manually add entries for dynamic paths the agent could not observe. Regenerate the configuration whenever you add new reflection calls or change dependencies.

The Native Image heap snapshot is a preinitialized heap containing all objects that exist at build time — static field values, string constants, and objects created during static initializer execution. When the image starts, this snapshot is loaded directly into memory as a contiguous block, giving the application immediate access to initialized objects without runtime allocation. The JVM heap at runtime is dynamic — objects are allocated as needed and garbage collected when no longer reachable. In a JVM, static fields start as default values and are initialized at class loading time; in Native Image, they are already populated in the snapshot. The snapshot eliminates the "warmup" phase where static initializers run and populate the heap on first access. For large applications, the snapshot can be tens of megabytes, but it replaces what would otherwise be dynamic allocation and initialization cost at startup.

The Substrate VM includes a thread management system similar to the JVM's: threads are created, scheduled, and managed by the runtime. Stack frames in the Substrate VM are simpler than in the JVM because there is no interpreter — all code is precompiled. Each thread has a native stack (on the OS), and the compiled code uses standard calling conventions for that platform. The key difference is that the Substrate VM does not have the complexity of deoptimization, OSR transitions, or safepoint polling in compiled code — since all code is statically compiled, there is no need for these JIT-era mechanisms. Thread coordination (locks, wait/notify) uses the same Java semantics but implemented through native synchronization primitives rather than JVM runtime services. For short-lived processes, the simpler stack model reduces overhead compared to JVM threads.

Native Image compiles Java bytecode to native machine code for a specific target platform — Linux x86-64, Windows x86-64, macOS ARM64, etc. The output is an ELF/PE/Mach-O binary that runs directly on the OS and CPU without any JVM layer. This means you must build a separate image for each target platform, just like any native C/C++ application. JVM applications are portable because the JVM interprets or JIT-compiles bytecode at runtime, abstracting away the platform differences. A .class file or JAR runs on any JVM that supports that Java version, regardless of the underlying OS and CPU. For teams deploying to multiple platforms, Native Image adds CI/CD complexity — you need to build and test on each target platform, or use cross-compilation infrastructure. The tradeoff is explicit: Native Image trades cross-platform portability for startup speed and memory footprint.

--static linking produces a native executable that has no external library dependencies — all libc, libpthread, and other system libraries are linked statically into the image. This makes the image fully self-contained and portable within its target OS family (e.g., Linux x86-64). You would use --static in containerized environments where the base image should not rely on the host's system libraries, in security-sensitive deployments where dynamic library loading is a concern, or when deploying to minimalist environments without standard library packages. The tradeoff is image size: static linking increases the binary size because library code is included. Additionally, static linking may not work with all native libraries (especially those usingdlopen-style runtime loading) because the linking must be resolved at build time. For most serverless and containerized microservice use cases, --static is recommended because it simplifies deployment and reduces attack surface.

In the JVM, java.lang.reflect.Proxy generates proxy classes at runtime using bytecode instrumentation — the JVM creates a new class file on the fly that implements the target interfaces and dispatches to an InvocationHandler. In Native Image, this dynamic generation cannot happen at runtime because all classes must be known at build time. Native Image handles this through proxy-config.json, which tells the analyzer which interface pairs should have proxy implementations generated at build time. The analyzer generates the proxy classes as part of the static analysis and includes them in the image. If you need runtime-generated proxies (like Spring's interface-based proxying), you must either configure them in proxy-config.json or use compile-time solutions like Spring's AspectJ weaving instead of runtime proxy generation. Missing proxy configuration causes UnsupportedOperationException or silent null returns at runtime.

GraalVM's Truffle framework is a language implementation toolkit that uses GraalVM as the execution engine for dynamically interpreted languages (JavaScript, Ruby, Python, etc.). Truffle interpreters are themselves Java programs that get compiled by GraalVM — either via JIT for maximum performance or via Native Image for fast startup. When a Truffle language is compiled with Native Image, the interpreter and its runtime support all compile to native code, giving guest language programs near-instant startup without a JVM layer. This is how GraalVM can run JavaScript, Python, and Ruby with startup times competitive with native implementations. Native Image's closed-world assumption is compatible with Truffle because the interpreter and all language runtime classes are known at build time — the dynamic behavior comes from the guest programs, not from the language implementation itself. The combination enables polyglot applications where each language component starts instantly.

Since all classes are loaded and initialized at build time, Native Image has no runtime class loading — there is no ClassLoader, no Class.forName() loading new classes, and no bytecode interpretation. This has security benefits: there is no way to load untrusted bytecode at runtime, reducing an entire attack vector. It also has memory benefits: no class loader metadata, no metaspace, no class unloading overhead. However, it means plugins or modules that load classes at runtime (like JDBC drivers, which are loaded via ServiceLoader) require special configuration. JDBC driver JARs must be included in the native image build, and the driver must be registered via static initialization rather than runtime loading. This is a common gotcha: a JAR that works fine on a JVM fails on Native Image because its class loading mechanism is not configured. Security-aware deployments benefit from the immutable, closed-world nature of the image — but must account for the class loading implications.

JNI calls in Native Image work through static linking of native libraries at build time. The native-image tool uses the JNI export from the compiled Java code to determine which native functions are needed, then links against the specified native libraries. You provide native library files (.h, .lib, .a, .so) and header files as inputs to the build. At runtime, the native functions are directly callable from Java through the normal JNI mechanism, but without a JVM interpreter — the call goes directly to the native code. The key difference from JVM-based JNI is that there is no lazy loading of native libraries at runtime; all linked native code is included in the image. JNI is commonly used for performance-critical operations (crypto, compression), interfacing with legacy C/C++ libraries, or accessing OS-specific features. Native Image supports JNI but requires that all native dependencies be known at build time and linked statically.

-H:+DeadCodeElimination=aggressive instructs the Native Image compiler to remove not only unreachable code detected by static analysis, but also code that is reachable but provably not used in the observed execution context. The standard dead code elimination removes methods and classes that the static analyzer cannot reach from the entry point. Aggressive mode goes further by looking for code paths that are reached but never actually execute based on constant conditions — for example, a method that is called but only with arguments that make it take an early return path. Aggressive dead code elimination can significantly reduce image size for large applications with extensive frameworks, but it increases build time and may remove code that is actually needed via reflection in ways the analyzer could not detect. Always test the resulting image to ensure functionality is preserved.

The image heap contains all objects that existed at build time — these are "frozen" objects that the GC treats as roots throughout the process lifetime. They are not garbage collected because they are part of the image file itself (loaded as a memory-mapped region) and are not allocated at runtime. The Substrate VM's GC manages only the runtime-allocated heap — objects allocated by the application during execution are collected normally. The preinitialized objects are accessible as roots for GC tracing. This design means the static memory footprint of a Native Image is predictable: the image heap size is fixed at build time and does not grow at runtime from static initialization. For short-lived processes, the runtime heap may be small or unused entirely if no new objects are allocated. The tradeoff compared to JVM behavior is that in a JVM, static fields are allocated on the heap and managed by the GC — in Native Image, they are in the image heap and not GC-managed, reducing GC pressure significantly.