Spring Boot 2.0: The Most Important Changes at a Glance

Spring Boot 2.0 Is Here -- and a Lot Is Changing

On March 1, 2018, Pivotal released Spring Boot 2.0 after over a year of development. This major release builds on Spring Framework 5.0 and introduces fundamental changes that affect nearly every aspect of development. We have spent the last few weeks evaluating several of our services and conducting initial migrations. Here is our summary of the most important new features -- and the pitfalls you should be aware of.

Spring Framework 5 as the Foundation

Perhaps the most significant change is the underlying platform. Spring Boot 2.0 is based on Spring Framework 5.0, and that has far-reaching consequences: Java 8 is now the minimum requirement. Anyone still on Java 7 needs to update the runtime first. At the same time, Spring Framework 5 brings official support for Java 9 -- a topic that is becoming increasingly relevant given Oracle's new release cadence.

The entire codebase now uses Java 8 features such as lambdas, streams, and the java.time API. This may sound obvious, but in practice it means that deprecated APIs have been consistently replaced. Anyone who has written custom configurations or extensions based on the old APIs will need to update them.

WebFlux: Reactive Programming in the Spring Ecosystem

The flagship feature of Spring Boot 2.0 is undoubtedly WebFlux -- the new reactive web framework. Alongside the classic Spring MVC, there is now a fully non-blocking stack built on Project Reactor that runs with Netty as the default server.

A simple reactive controller looks like this:

@RestController
@RequestMapping("/api/products")
public class ProductController {

    private final ProductRepository repository;

    public ProductController(ProductRepository repository) {
        this.repository = repository;
    }

    @GetMapping("/{id}")
    public Mono<ResponseEntity<Product>> getProduct(@PathVariable String id) {
        return repository.findById(id)
                .map(ResponseEntity::ok)
                .defaultIfEmpty(ResponseEntity.notFound().build());
    }

    @GetMapping
    public Flux<Product> getAllProducts() {
        return repository.findAll();
    }
}

Instead of returning a single object, you work with Mono<T> (zero or one element) and Flux<T> (zero to n elements). The server does not block any thread while waiting for database results -- a decisive advantage under high load.

However, an important note is warranted here: WebFlux is not a replacement for Spring MVC. If you are building classic JDBC-based applications, you will hardly benefit from it because JDBC itself is blocking. Only with reactive database drivers -- such as MongoDB with the Reactive Streams Driver or R2DBC for relational databases, which is still in an early stage -- does the reactive stack reach its full potential. For most of our existing services, Spring MVC therefore remains the right choice for now.

Actuator: Completely Revamped

The Spring Boot Actuator has undergone a fundamental overhaul. The changes are so extensive that they are likely to cause the most effort during migration.

An overview of the key changes:

• New Endpoint Model: All Actuator endpoints are now grouped under /actuator by default. The health endpoint is therefore no longer accessible at /health, but at /actuator/health.
• Security by Default: Only /actuator/health and /actuator/info are exposed via HTTP by default. All other endpoints must be explicitly enabled.
• Technology-agnostic: Endpoints work with both Spring MVC and WebFlux -- the same implementation serves both stacks.

Configuration is now significantly more granular via application.yml:

management:
  endpoints:
    web:
      exposure:
        include: health, info, metrics, prometheus
  endpoint:
    health:
      show-details: when-authorized
  server:
    port: 9090

Anyone who has previously implemented custom Actuator endpoints will need to migrate them to the new @Endpoint model. The effort is manageable, but should be planned for.

Micrometer: Finally a Proper Metrics Framework

Spring Boot 1.x had its own rather rudimentary metrics system. In 2.0, this is replaced by Micrometer -- essentially an SLF4J for metrics. Micrometer abstracts metrics collection and supports a wide range of monitoring systems: Prometheus, Datadog, InfluxDB, Graphite, and many more.

In practice, this means: you include micrometer-registry-prometheus, configure the Actuator endpoint, and immediately have JVM metrics, HTTP request statistics, and custom business metrics in Prometheus format. For our Kubernetes deployments, where we already use Prometheus, this is a huge win -- no more manual instrumentation, no third-party libraries that you have to wire up yourself.

Kotlin Support

Spring Framework 5 and thus Spring Boot 2.0 offer first-class Kotlin support. This ranges from null-safety annotations to extensions to dedicated DSLs for bean definition and routing. Anyone evaluating or already using Kotlin will find a significantly more mature integration than in the 1.x line.

The Kotlin DSL for functional routing in WebFlux is particularly elegant -- but that is a topic for a separate article.

Gradle Plugin: Rewritten from Scratch

The Gradle plugin for Spring Boot has been rewritten from the ground up and now requires Gradle 4.0 or newer. Anyone still on Gradle 3.x needs to update Gradle first. The new plugin is more powerful and flexible but also introduces breaking changes: some task names have changed, and fat JAR configuration works differently than before.

Migrating from 1.5: What to Watch Out For

We have now migrated three services from Spring Boot 1.5 to 2.0 and identified several recurring themes.

Property Renames: Numerous configuration properties have been renamed. server.context-path is now server.servlet.context-path, spring.http.multipart became spring.servlet.multipart. Spring provides the spring-boot-properties-migrator module, which detects deprecated properties at runtime and logs warnings. We recommend temporarily including this module to find all affected areas.

Spring Security: The auto-configuration for Spring Security has fundamentally changed. The previous behavior, where everything was secured by default and you defined exceptions, no longer applies. Instead, you must provide your own SecurityFilterChain configuration. This enforces more explicit security configurations -- ultimately a good thing, but a point that should not be overlooked during migration.

Dependency Versions: With Spring Boot 2.0, many third-party libraries are bumped to newer versions. Hibernate 5.2, Tomcat 8.5, Jackson 2.9 -- anyone who has pinned specific versions should check compatibility.

Removed Classes and Methods: Some APIs marked as @Deprecated in 1.5 have been removed in 2.0. Anyone who ignored compiler warnings in 1.5 will now get compile errors. Our tip: first update to the latest 1.5.x version, fix all deprecation warnings, and then switch to 2.0.

Our Verdict After the First Few Weeks

Spring Boot 2.0 is a solid major release. The reactive capabilities with WebFlux are impressive, even though for most classic web applications they are not yet a compelling reason to migrate. The revamped Actuator endpoints and Micrometer integration, however, are relevant for anyone running services in production -- and that alone makes the upgrade worthwhile.

The migration from 1.5 is not a walk in the park and should not be underestimated. Two to three days per service is realistic, depending on complexity and the number of Spring Boot features used. Our advice: don't migrate all services at once. Start with a non-critical service, gain experience, and then proceed incrementally.

Spring Boot 1.5 will be supported until August 2019. So there is time -- but you shouldn't put off the migration indefinitely.