Native Image is a technology to ahead-of-time compile Java code to a standalone executable, called a native image. This executable includes the application classes, classes from its dependencies, runtime library classes, and statically linked native code from JDK.
Native Image is a technology to ahead-of-time compile Java code to a standalone executable, called a native image. This executable includes the application classes, classes from its dependencies, runtime library classes, and statically linked native code from JDK. It does not run on the Java VM, but includes necessary components like memory management, thread scheduling, and so on from a different runtime system, called “Substrate VM”. Substrate VM is the name for the runtime components (like the deoptimizer, garbage collector, thread scheduling etc.). The resulting program has faster startup time and lower runtime memory overhead compared to a JVM. — Oracle
GraalVM is a Java Development Kit (JDK) written in Java. The open-source distribution of GraalVM is based on OpenJDK, and the enterprise distribution is based on Oracle JDK. As well as just-in-time (JIT) compilation, GraalVM can compile a Java application ahead of time. This allows for faster initialization, greater runtime performance, and decreased resource consumption, but the resulting executable can only run on the platform it was compiled for.
With just-in-time compilation, portions of the program are dynamically compiled into machine code by the Java Virtual Machine (JVM) while it is executing and analyzing the application's bytecode. JIT compilation enhances performance by optimizing code segments that are often run.
Written by
Software engineer passionate about building scalable systems, exploring new technologies, and sharing knowledge through writing.
Get in touchWhat if you could get full distributed tracing on a plain Java HTTP server without adding any SDK, agent, or instrumentation code? This article walks through using Grafana Beyla and eBPF to automatically capture OpenTelemetry traces from a pure Java application, exporting them straight to Jaeger.
Is reactive programming still necessary in Java? This article explores the limitations of platform threads, the cost of reactive programming, and how Java Virtual Threads (Project Loom) offer a simpler path to scalable concurrency — without the complexity tax.
In contrast, the process of converting source code into machine code prior to the program being executed is known as "ahead-of-time compilation." AOT compilation involves compiling the program in advance, usually during the build step, or at least all of its major components. There is no need for further compilation during runtime because the generated binary is platform-specific.
Since the difference between the two types are clear, the following sections will be focused on the use of AOT and its cons.
Any class that has to be known at executable construction time in order to be accessible by name at executable runtime. For instance, myClass has to be in a configuration file in order to be called using Class.forName("myClass"). A ClassNotFoundException will be issued at runtime, as if the class was not found on the class path or was inaccessible, if a configuration file is provided but does not contain a class that is necessary for dynamic class loading.
The native-image tool has to be aware of all the classes, methods, and fields that should be available through reflection at build time. In an attempt to resolve these software pieces, Native Image looks for calls to the Reflection API using static analysis. The program parts that are reflectively accessible at runtime must be defined at build time in a configuration file or by using RuntimeReflection from a Feature in the event that the analysis is unsuccessful.
In the same manner that Java code uses the reflection API, native code may access Java objects, classes, methods, and fields by name. Java assets that may be accessed by name using JNI need to be listed in a configuration file provided to the native-image tool during build time.
Similar to JNI, class metadata information is needed for Java serialization, and it has to be supplied in a configuration file to the native-image tool during build time. Still, security flaws in Java serialization have been around for a while. The current serialization system will soon be replaced with a new one that avoids these issues, according to an announcement made by the Java architects.
More limitations and differences are discussed here.