Spring Native Beta is now available bringing a new way to deploy Spring applications. Spring Native lets you compile Spring applications to native images using the GraalVM native-image compiler.

What's the advantage in that? Instant startup, instant peak performance, and reduced memory consumption, since the native Spring applications are deployed as a standalone executable, well docker image, without including a JVM installation.

What's the disadvantage? It's that the GraalVM build process, which tries to make the most optimal image possible, throws a lot of stuff out. This could be dependencies, resources or parts of your code.

The way to mitigate this is by feeding GraalVM a bunch of configurations files that will cause it to include the extra material in the image.To automate this process you annotate your code with hints in order to direct the Spring AOT plugin to generate those configurations files.

However, the Spring Native bundle includes spring-native-configuration which, in Spring Boot's true spirit, handles it for you. It contains configuration hints for Spring's classes therefore it takes care of the framework without further ado. Some drivers have already been annotated, for instance the MySQL driver supports Spring Native with hints that allow generation of the right entries in native image files, reflect-config.json, resource-config.json and native-image.properties

@NativeHint(
    trigger = Driver.class,
    options = "--enable-all-security-services",
    types = @TypeHint(types = {
       FailoverConnectionUrl.class,
       FailoverDnsSrvConnectionUrl.class,
       // ...
    }), resources = {
	@ResourceHint(patterns = "com/mysql/cj/TlsSettings.properties"),
	@ResourceHint(patterns = "com.mysql.cj.LocalizedErrorMessages",
                      isBundle = true)
})
public class MySqlHints implements NativeConfiguration {}

The Spring AOT build plugin is available for bot Maven and Gradle and is invoked before running your application and tests, and may potentially require additional IDE configuration. The generated files sources are available and can be inspected if there's the need to.

That need arises in the following are situations where
specifying additional native configuration is required:

• When reflection-based serialization is used in a programmatic API like WebClient with Jackson
  
  
• When you try to use a feature or library not yet supported by Spring Native
  
  
• When you are want to specify native configuration related to your own application.

In those circumstances, you can annotate the classes already annotated with @Configuration or @SpringBootApplication with @NativeHint, or in simple enough cases using @TypeHint directly (a @NativeHint is a container for many kinds of configuration including @TypeHints).

This means that in most of the cases, your Spring boot app, JPA and Spring Security included, will compile to native just fine, except if you have some fancy dependencies which you'll need to include yourself by hints or tweaking the generated configuration files.

Besides JPA and Spring Security , Spring Native also works with Spring Cloud so that you can compile a Spring Cloud Function to an image and then deploy it as is on Google Cloud Run, or as a AWS Lambda!

Although in Beta, Spring Native is still experimental which means that you must use it sparingly and not on production code. Still bootstraping a new application on start.spring.io includes a build option for Native already. And on the roadmap there's a lot to look forward to. 

More Information

Roadmap

Documentation

Related Articles

Netflix's GraphQL for Spring Boot

The Insider's Guide to the Java Web Developer Nanodegree - 2

Learn How To Do Java On Azure

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info