How Spring Native Beta Turns Spring Apps into Ultra‑Fast Native Executables

Introduction

After a year and a half of work, the Spring Native beta is now available on start.spring.io, allowing Spring applications to be compiled into native images with GraalVM, supporting Java and Kotlin.

Using

mvn spring-boot:build-image

or

gradle bootBuildImage

you can create an optimized container image that includes a minimal OS layer and a small executable (e.g., a 50 MB image containing Spring Boot, MVC, Jackson, Tomcat, JDK, and the application).

Typical use cases include serverless functions with Spring Cloud Function, cost‑effective microservice hosting, Kubernetes platforms such as VMware Tanzu, and creating optimal container images that bundle Spring apps and services.

Team Collaboration

The beta is the result of deep collaboration between the Spring team and the broader Spring ecosystem (Spring Framework, Boot, Data, Security, Cloud, Initializr) and close work with the GraalVM team to improve native image compatibility and size.

GraalVM engineer Vojin Jovanovic remarks on the pleasant cooperation and the roadmap toward broader native compilation usage.

Supported Scope

Spring Native has moved from alpha to beta, expanding support to a subset of Spring projects. Each Spring Boot 2.x patch releases a corresponding Spring Native version (e.g., 0.9.0 for Boot 2.4.3, 0.9.1 for Boot 2.4.4). Documentation is now available as a single‑page HTML or PDF, with Javadoc for native hints.

start.spring.io Integration

Stéphane Nicoll added Spring Native support to start.spring.io, making it the quickest way to generate a Spring Native project. Adding the dependency automatically configures Maven or Gradle plugins; the application code itself does not need to change.

Check the generated

HELP.md

for useful links and a list of dependencies that are not supported natively.

Ahead‑of‑Time (AOT) Transformation

Native images have a fixed classpath at build time, requiring explicit configuration for reflection, resources, and proxies. Spring’s AOT plugins (Maven and Gradle) perform ahead‑of‑time analysis using Andy Clement’s inference engine to generate

reflect-config.json

,

resource-config.json

, and other native‑image configuration files.

When inference cannot determine configuration, developers can use

@NativeHint

annotations to supply type, resource, and option hints, as shown in the MySQL driver example.

<code>@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 {}
</code>

Developers can also annotate classes with

@Configuration

or

@SpringBootApplication

to trigger AOT processing, for example:

<code>@TypeHint(types = Book.class)
@SpringBootApplication
public class WebClientApplication {
    // …
}
</code>

The goal is to reduce the amount of additional native configuration needed, improving compatibility and lowering image size.

Conclusion

Spring’s native strategy focuses on making the core Spring infrastructure native‑friendly without requiring massive changes to existing applications, and on collaborating with the GraalVM team to narrow the gap between JVM and native execution. Upcoming work includes broader JVM ecosystem testing and further AOT enhancements.