Spring custodian Pivotal has released the widely anticipated Spring Boot 2.0, the first version number increment since its inauguration in June 2014, and the first release since the popular 1.5 version, released in February 2017.
Spring Boot combines an opinionated convention over configuration structure and auto-configuration, with the concept of technology "starters" and a robust lifecycle with injection based defaults, in order to help developers easily launch new applications that may include a wide variety of technology selections, while keeping overlapping transitive dependencies consistent.
In the nearly four years since its inception, Spring Boot Initializr has generated over 8 million projects, making Spring Boot a standard for initializing JVM applications across the technology spectrum.
Supported Spring Boot technologies are classified under Core, Web, SQL/NoSQL, Cloud/Pivotal Cloud Foundry and other categories, that together encompass most of the popular frameworks used in contemporary applications.
InfoQ spoke to Spring Boot lead Phil Webb about the new release.
InfoQ: Let’s start with the big question - Spring Boot is already one of the most important platforms added to the Spring portfolio since its inception. What does Spring Boot 2.0 bring to the table?
Phil Webb: Spring Boot 2.0 really has two major goals. The first is support for reactive programming (non-blocking applications, that are asynchronous, event-driven and require a small number of threads to scale). We’re providing auto-configuration for all Spring projects that support reactive programming. This includes Spring WebFlux, which shipped with Spring Framework 5.0. You also now get the choice of Netty as an embedded server for the first time.
The second goal is a lot less glamorous; we’re trying to refine decisions that we made in the 1.x line to ensure that we have a great base to build on going forward. There’s been a lot of cleanup and refactoring in this release.
InfoQ: Is there anything we have grown accustomed to in 1.5 that we will need to change?
Webb: For most existing users, nothing major has changed. We still offer convention over configuration. We still auto-configure Spring, based on what is in your classpath. We still back-off if you define your own beans. You can still configure things with properties files, yaml files or environment variables.
Items where people might notice a difference are security configuration and OAuth. OAuth functionality is now being handled by a dedicated Spring Security project.
InfoQ: Is the 2.0 release backward compatible?
Webb: The most obvious impact for people upgrading will be their properties files. We’ve renamed quite a few properties to make things more consistent. If you’re migrating an existing project and you use an IDE that has good Spring Boot support, you’ll get warnings if you try to use old property names. We’ve also got a helpful migrator JAR that will map the old names to the new ones to give you a chance to gradually rename things.
Other than that, the amount of change needed will depend on how deeply your project integrates with Spring Boot. For example, if you’re using standard auto-configured features and customizing things with a few properties, then there really shouldn’t be any migration pain. If you’re doing something a little more complex, you might need some code migration. The user-facing touchpoints that have changed the most are the embedded servlet container support, actuator endpoints, and metrics. Actuator endpoints especially are quite different in 2.0, but if you take the time to migrate you’ll get Jersey and WebFlux support for free. The migration guide goes into more details, and has information on the migrator jar.
InfoQ: Are the old properties deprecated, or are they no longer supported?
Webb: The old property names are only supported if you use the migrator project. This gives us the best of both worlds as we can rename properties and keep our own codebase clean, but people still have a migration path. It also means that once your migration is done and you remove the migrator, you’re no longer paying a performance penalty to check old names.
InfoQ: Does it require Spring Framework 5.0?
Webb: Yes. We’ve always aligned and required the latest Spring Framework version, and Spring Boot 2.0 is no exception. We’ll expect Spring Framework 5.0.3 or later.
InfoQ: What is the minimum Java version?
Webb: Java 8 is now the minimum required version. We make heavy use of Java 8 features and classes so there is no way to run Spring Boot 2.0 on an early version of Java.
InfoQ: Is Java 9 fully supported?
Webb: Java 9 is fully supported. We even have a CI job to ensure that Spring Boot builds with Java 9 and all our samples run. This wiki page has more details: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-with-Java-9
InfoQ: How about HTTP/2?
Webb: You can use HTTP/2 with Jetty, Undertow or Tomcat. Details are in the reference documentation, but it’s basically as easy as adding `server.http2.enabled=true` in your properties and configuring SSL (we don’t support h2c, the cleartext HTTP/2 protocol).
InfoQ: I assume you will continue to support popular app servers and frameworks, such as Tomcat, Jetty, and Thymeleaf?
Webb: We provide support for the embedded Tomcat 8.5, Jetty 9.4 and Undertow 1.4. For WebFlux applications you can also use embedded Netty 4.1. You can also still deploy Spring Boot applications to application servers, and we test each build against TomEE, Wildfly, WebSphere Liberty Profile and Glassfish.
The minimum supported Thymeleaf version is 3.0, which continues to have excellent Spring support, including engine throttling for reactive applications.
InfoQ: Will we be seeing new Spring Boot versions to coincide with Oracle’s new six month release cadence?
Webb: Spring Boot 2.0 is a feature-driven release. We can’t call it done until we have a complete reactive story. Going forward, the next few releases are much more iterative, and it will be easier to support date-based releases. Having said that, Spring Boot releases are not going to exactly match Oracle’s release cadence. We’re planning to follow Spring Framework’s lead and try to release a couple of months after them.
InfoQ: We hear about Spring Boot in so many new projects, but what are the adoption metrics?
Webb: For the metrics we’re able to track, we’re very happy with the adoption rate. Of course, being an open source project, it’s very hard to get exact figures. People are free to use the software however they see fit and there’s no requirement to report usage information back to us.
We used to share maven downloads as a metric, but we’ve come to prefer using the number of projects generated from Spring Initializr (start.spring.io) lately. While the current growth rate will naturally flatten out over time, 2017 saw 4.7M Initalizr projects generated, representing a 256% growth from 2016. Maven downloads are dramatically higher raw numbers, and at 300% growth, the two growth curves correlate nicely, which is very gratifying to see.
But one of my favorite metrics is contributions back to the project. I’m very pleased that we now have over 400 contributors to the codebase.
Publicly available data looks promising as well, with Spring Boot ranked 1st on GitHub for Java projects by forks, (moving Spring framework to the #2 spot), and 7th on GitHub for Java projects by stars.
InfoQ: Is there a plan to end version 1 support at any time?
Webb: Major versions of Spring projects are usually supported for three years, and minor releases for 12 months. Since Spring Boot 1.0 was released in 2014 and 1.5 early 2017 we’ve actually already met those usual support criteria. Of course, we fully expect people will need time to upgrade so we intend to support 1.5 for at least the next year.
InfoQ: What would be an example of reactive support that would not have been available previously? Do I need to be using WebFlux and Reactor to benefit from the reactive support, or will the implementation provide me with reactive benefits generally, and if so how?
Webb: I think that Spring has a fairly unique position on reactive programming. Whilst it’s possible to jump in with both feet and adopt a fully reactive stack, it’s also possible to start much smaller. You can actually return reactor types (Flux and Mono) from a Servlet-based MVC application and they will work. You don’t get exactly the same benefit, but you do get a chance to try the reactive APIs without moving entirely to a new architecture. Spring Framework 5.0 also introduces a new WebClient API, which provides a very natural way to call remote web services. The API makes heavy use of project reactor types, allowing you to compose operations in a very natural way.
It’s important to realize, however, that the reactive programming option is something we offer in addition to the traditional synchronous, blocking model; the team is committed to providing developers the option for both models and will continue to invest effort on both fronts.
InfoQ: Besides Java, what other JVM languages are supported natively?
Webb: You can pretty much write Spring Boot applications using any JVM language that has good Java interoperability. Groovy and Kotlin are both excellent choices if you want to develop in something other than Java.
InfoQ: Python has been exploding on the scene; does the Spring team have anything in the works for the Python platform?
Webb: I’m not aware of any Spring projects that are currently using Python. There’s obviously many years of development effort behind Spring, so it generally makes sense for us to target JVM languages. The most recent alternative language investment has been in Kotlin. Spring Framework and Spring Boot both ship with Kotlin extensions that provide a first-class Kotlin experience out of the box.
InfoQ: You mentioned the security overhaul -- will that be using the new Spring Security 5.0 introduced late last year?
Webb: Yes, Spring Boot 2.0 requires Spring Security 5.0 as a minimum.
InfoQ: Can you talk about the specific changes to security?
Webb: Spring Security itself has introduced a whole set of new APIs in order to support reactive programming. If you’re familiar with existing Spring Security concepts, you’ll find the reactive equivalents quite easy to use.
Spring Boot has also taken the opportunity to simplify security configuration in 2.0. Some of the more complex customizations that we supported in 1.5 have been removed in favor of a much simpler model. This blog post explains in a lot more detail the rationale for the changes.
InfoQ: Micrometer metrics, is that a new starter or is it built in? Are those exposed in JMX?
Webb: Micrometer.io replaces the metrics APIs that were previously part of Spring Boot itself. We automatically provide instrumentation for a variety of technologies (Spring MVC, RestTemplate, DataSource Pools etc). By making use of Micrometer, we’re able to expose metrics over JMX and HTTP in a similar way to Boot 1.5. The really exciting thing about Micrometer is it can also export metrics to lots of different backends. We’re including export support for Atlas, Datadog, Ganglia, Graphite, New Relic, Prometheus, SignalFX, and StatsD.
About the interviewee
Phil Webb works for Pivotal and is the current lead of the Spring Boot project. He’s originally from the UK, but now lives with his family in California.