Native image compilation - what’s new, and what’s next?

Native image compilation has been an emerging technology in the Java community for a number of years. In a sentence, it offers a smaller memory footprint and dramatically faster startup times which makes it especially well suited for Serverless use cases. Earlier in 2022, at I/O, we discussed the technology in more depth and how to get started with the project during its experimental phase. Since then, the project has gained first class support, as promised at SpringOne 2021. This post will discuss where the project has gone this year, what has changed regarding the getting started experience, and provide updated materials to help you leverage the technology on Google Cloud.

What’s new?

In the past year the Spring Native project has made a number of notable improvements in terms of compatibility, bug fixes, and documentation improvements before being superseded by Spring Boot 3’s official native image support. The result of this first class support is that Native Image Support is available as a developer tooling option in the Spring Initializer, and requires far less configuration to get started. It’s also gotten easier to download GraalVM JDKs since the Graal team released the one-line JDK download method.

What else can trip us up?

There are a number of topics that remain somewhat challenging when adopting Native Image compilation. 

Reachability

Ensuring that all libraries that your project makes use of are reachable can sometimes require some specific library metadata to be provided. It’s difficult to provide general advice for these types of issues, but Community Reachability project can save you time and effort when troubleshooting them.

Native testing

Testing native images can result in discovering unexpected differences when compared to apps running on the JVM. This is especially common when tests involve backing services like database access or file storage. It can also take a significant amount of time to build artifacts for these tests. Fortunately this process is steadily improving, with relevant bug fixes coming out periodically and open-source testcontainers being added to the shared metadata repository.

Monitoring

Monitoring a Native Image application is another non-obvious topic, since you’re no longer shipping your application with a JVM. While Native binaries can be monitored just like any other binary, there are also some specific solutions being provided for Native image compilation, such as JFR support. This is a useful option to have in mind, since it provides a similar experience to monitoring a traditional Java workload. The Graal team has provided a useful guide on the topic, which is a good starting point.

What’s next?

Stay tuned for more materials intended to help you make use of Native image compilation on Google Cloud.
For an example of a complete project that makes effective use of native image compilation, check out our Pic-A-Daily codelab. It stores pictures in a Storage bucket, handles file creation events, processes the images with a Native app image and the Native vision client libraries. For reference documentation on Native image support for other client libraries, refer to our Client Libraries guide.