Article originally posted on InfoQ. Visit InfoQ

GraalVM is known for compiling Java into small native executables that start much faster than traditional Java programs. Release 22.2 by Oracle Labs addresses a long-standing pain point by introducing a configuration repository for Java libraries. Native Java compilation uses less memory, and the GraalVM distribution runs better on Apple Silicon and is smaller.

Native compilation makes Java more competitive in the cloud. Quarkus, Micronaut, and Helidon support GraalVM in production today. Spring 6 and Spring Boot 3 plan to do so by the end of this year. InfoQ published an article series on this topic.

Why does GraalVM need a configuration repository? Unlike regular Java, native Java executables can’t dynamically load new code when running. That’s why GraalVM’s native compiler “Native Image” needs to know all classes, methods, and fields used at runtime (“closed-world assumption”). Native Image detects that automatically with a reachability analysis. But dynamic Java features such as reflection and proxies hide some code from that analysis. Applications and libraries with these dynamic features must provide configuration hints to Native Image, or they won’t work at all in native Java.

Until now, Java developers had to provide these hints for libraries that didn’t ship with their GraalVM-supporting Java framework. The GraalVM Reachability Metadata Repository promises to remove that burden: GraalVM 22.2 reads hints (renamed into “reachability metadata”) from this new central repository. It is a collaboration between GraalVM, Micronaut, Spring Boot, and Quarkus and welcomes contributions.

Native Image now uses less RAM during compilation. For example, building the Spring PetClinic application uses just 2 GB. Memory-constrained CI environments or cloud services, like GitHub Actions, benefit from this resource reduction.

Native Image compiles not only JVM languages like Java, Scala, or Kotlin but also JavaScript, Python, Ruby, R, and WebAssembly. Python got an experimental bytecode interpreter with faster startup and better performance in this release. JavaScript interoperability with objects from other languages has improved.

The GraalVM distribution is smaller because it is more modular. It no longer includes the runtimes for JavaScript and LLVM or VisualVM. On Linux, this reduces the Java 17 GraalVM distribution size by 42% – from 431 MB to 251 MB.

With release 22.2, native Java executables can dump the memory heap into a file, as traditional Java applications can. That’s possible in three ways: By calling a runtime API, sending an OS signal to the application, or on exit. The release also includes faster escape analysis during compilation, improved debugging on Linux, and experimental strip mining optimization for counted loops.

The commercial GraalVM Enterprise Edition now has experimental Apple Silicon support, which was included in the Community Edition with the release of GraalVM 22.1 in April this year. Other GraalVM components now also support Apple Silicon in both editions, such as JavaScript, LLVM, Ruby, Java on the Truffle VM, and WebAssembly. The Enterprise Edition can also include a Software Bill of Materials (SBOM) in the CycloneDX format in the native executable.

OpenJDK manages the evolution of the Java language. But GraalVM is not part of OpenJDK as it belongs to Oracle Labs. Still, GraalVM will remain the only option for native Java in the coming years, as OpenJDK delayed its native Java plans in Project Leyden.