GraalVM 22.2 adds library configuration repository
GraalVM is known for compiling Java into small native executables that start much faster than traditional Java programs. Oracle Labs version 22.2 fixes a long-standing issue 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 has published a series of articles on this subject.
Why does GraalVM need a configuration repository? Unlike standard Java, native Java executables cannot dynamically load new code at runtime. This is why the native “Native Image” compiler of GraalVM must know all the classes, methods and fields used during execution (“closed world assumption”). Native Image detects it automatically through an accessibility analysis. But dynamic Java features like reflection and proxies hide some of the code from this analysis. Applications and libraries with these dynamic features must provide configuration hints to Native Image, otherwise they won’t work in native Java at all.
Until now, Java developers had to provide these tips for libraries that didn’t ship with their GraalVM-enabled Java framework. The GraalVM Accessibility Metadata Repository promises to remove this burden: GraalVM 22.2 reads indices (renamed to “Accessibility 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 when compiling. For example, building the Spring PetClinic app only uses 2GB. CI environments or memory-constrained cloud services like GitHub Stocks benefit from this resource reduction.
With version 22.2, native Java executables can dump the heap of memory to a file, as can traditional Java applications. This is possible in three ways: by calling a runtime API, by sending a signal from the operating system to the application, or by exiting. The release also includes faster escape parsing when compiling, improved debugging on Linux, and an experimental strip mining optimization for counted loops.
OpenJDK manages the evolution of the Java language. But GraalVM is not part of OpenJDK because it belongs to Oracle Labs. Still, GraalVM will remain the only option for native Java for years to come, as OpenJDK has delayed its native Java plans in Project Leyden.