Spring Boot 3.0 RC1 has just been released and GA is behind the corner. One of the most important new features is a support for building GraalVM native images.
There has been a lot of hype around native images - for good reasons. In comparison to running on JVM, it brings following benefits:
- extremely fast application startup time
- low memory consumption
- minimizes vulnerability
- produces compact packages
But there are some downsides too - some specific to GraalVM, some specific to how Spring supports it.
Potentially worse runtime performance
It is often said that native image is faster than the JVM equivalent. It may or may not be and it heavily depends on what do you mean by "faster".
Unquestionably the startup time is orders of magnitude faster than on the traditional JVM, but the actual latency and throughput may be worse on the native image - there is no JIT compiler that optimizes code execution paths in runtime.
GraalVM team at Oracle is actively working on Native Image performance so eventually the differences may become (or have already become) negligible.
Ideally, run you own performance tests to find out how your application behaves as a native image and how as traditional JVM application.
Native hints for dependencies
While all projects from the Spring umbrella - including their dependencies - have been adjusted to work well with native images - there is a chance that you will want to use a dependency does not support native image out of the box.
If you are lucky, the support for it is already commited to GraalVM Reachability Metadata repository, but if not - you will be doing the work of finding out what hints specific to this library GraalVM needs.
You will either have to limit yourself to dependencies provided by the framework, or account additional efforts for making the dependencies native image friendly.
Read how to provide custom native hints.
Ideally libraries authors include all the native hints required by GraalVM in the libaries themselves, but we are not there yet.
No support for Spring Profiles
To build a native image, Spring beans configuration must be fixed during the build time. This means that beans cannot change in runtime or to put it in different words - beans arrangement cannot depend on the environment (environment variables, system properties, external configuration sources).
Effectively, you cannot use @Profile or @ConditionalOnProperty annotations to configure if bean will be created. When these annotations are in place, only the values known during the build time will be taken into account.
Significantly longer build times
Building native image takes significantly more time than building JVM equivalent. Ideally, you won't build a native image on your local machine but leave it to a CI server.
What about running tests? While you can just run regular tests on JVM, the more non-standard native image specific code you have, the more you will need to run your tests in the native mode to gain enough confidence to run it in production or even push code changes to the repository.
Luckily, Spring Boot provides a simple way to run tests in the native mode:
With Maven:
$ mvn -PnativeTest testWith Gradle:
$ gradle nativeTestRead more about Testing GraalVM Native Images.
With every GraalVM release build times get shorter - I hope this eventually becomes a non-issue.
Conclusion
With all these drawbacks I still believe that GraalVM is a fantastic game changing technology for the Java ecosystem, and I think there is a high chance that native image eventually becomes the default target build type we choose for Spring Boot applications.
I hope that this short blog post will help you with taking the decision if your application should be native or should run on traditional JVM.
