What is native image?

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

What is GraalVM?

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.

JIT vs AOT compilations

What is just-in-time compilation?

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.

When to use JIT?

• Long-running apps where speed during execution is crucial.
• Making use of runtime profiling-based adaptive optimizations.
• Making use of JVM capabilities like byte code verification and dynamic class loading.

What is ahead-of-time compilation?

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.

When to use AOT?

• Making executables that stand alone to facilitate distribution and deployment.
• Settings with limited memory when it is essential to reduce memory footprint.
• Certain applications, such as server-less operations or short-lived processes, have crucial starting time requirements.

Since the difference between the two types are clear, the following sections will be focused on the use of AOT and its cons.

AOT is great but what’s the catch?

Dynamic Class Loading

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.

Reflection

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.

Java Native Interface (JNI)

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.

Serialization

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.