1. Overview
Spring Boot brings an opinionated approach to the Spring ecosystem. First released in mid-2014. Spring Boot has been through a lot of development and improvement. Its version 2.0 is today getting ready for release at the beginning of 2018.
There are different areas where this popular library tries to help us out:
- Dependency management. Through starters and various package manager integrations
- Autoconfiguration. Trying to minimize the amount of config a Spring app requires to get ready to go and favoring convention over configuration
- Production-ready features. Such as Actuator, better logging, monitoring, metrics or various PAAS integration
- Enhanced development experience. With multiple testing utilities or a better feedback loop using spring-boot-devtools
In this article, we’ll explore some changes and features planned for Spring Boot 2.0. We’ll also describe how these changes might help us become more productive.
2. Dependencies
2.1. Java Baseline
Spring Boot 2.x will no longer support Java 7 and below, being Java 8 the minimum requirement.
It’s also the first version to support Java 9. There are no plans to support Java 9 on the 1.x branch. This means if you want to use the latest Java release and take advantage of this framework, Spring Boot 2.x is your only option.
2.2. Bill of Materials
With every new release of Spring Boot, versions of various dependencies of the Java ecosystem get upgraded. This is defined in Boot bill of materials aka BOM.
In 2.x this is no exception. It makes no sense to list them, but we can have a look at spring-boot-dependencies.pom to see what versions are being used at any given point in time.
A few highlights regarding minimum required versions:
- Tomcat minimum supported version is 8.5
- Hibernate minimum supported version is 5.2
- Gradle minimum supported version is 3.4
2.3. Gradle Plugin
The Gradle plugin has been through major improvement and some breaking changes.
To create fat jars, bootRepackage Gradle’s task gets replaced with bootJar and bootWar to build jars and wars respectively.
If we wanted to run our apps with the Gradle plugin, in 1.x, we could execute gradle bootRun. In 2.x bootRun extends Gradle’s JavaExec. This implies it is easier for us to configure it applying the same configuration we’d typically use in classic JavaExec tasks.
Sometimes we find ourselves wanting to take advantage of Spring Boot BOM. But sometimes we don’t want to build a full Boot app or repackage it.
In this regard, it is interesting to know that Spring Boot 2.x will no longer apply the dependency management plugin by default.
If we want Spring Boot dependency management we should add:
apply plugin: 'io.spring.dependency-management'
This gives us greater flexibility with less configuration in the above-mentioned scenario.
3. Autoconfiguration
3.1. Security
In 2.x the security configuration gets dramatically simplified. By default, everything is secured, including static resources and Actuator endpoints.
Once the user configures security explicitly, Spring Boot defaults will stop affecting. The user can then configure all access rules in a single place.
This will prevent us from struggling with WebSecurityConfigurerAdapter ordering issues. These problems used to happen usually when configuring Actuator and App security rules in a custom way.
Let’s have a look at a simple security snippet that mixes actuator and application rules:
http.authorizeRequests()
.requestMatchers(EndpointRequest.to("health"))
.permitAll() // Actuator rules per endpoint
.requestMatchers(EndpointRequest.toAnyEndpoint())
.hasRole("admin") // Actuator general rules
.requestMatchers(PathRequest.toStaticResources().atCommonLocations())
.permitAll() // Static resource security
.antMatchers("/**")
.hasRole("user") // Application security rules
// ...
3.2. Reactive Support
Spring Boot 2 brings a set of new starters for different reactive modules. Some examples are WebFlux, and the reactive counterparts for MongoDB, Cassandra or Redis.
There are also test utilities for WebFlux. In particular, we can take advantage of @WebFluxTest. This behaves similarly to the older @WebMvcTest originally introduced as part of the various testing slices back in 1.4.0.
4. Production-Ready Features
Spring Boot brings some useful tools to enable us to create production-ready applications. Among other things, we can take advantage of Spring Boot Actuator.
Actuator contains various tools for simplifying monitoring, tracing, and general app introspection. Further details about actuator can be found in our previous article.
With its 2 version actuator has been through major improvements. This iteration focus on simplifying customization. It also supports other web technologies, including the new reactive module.
4.1. Technology Support
In Spring Boot 1.x only Spring-MVC was supported for actuator endpoints. In 2.x, however, it became independent and pluggable. Spring boot now brings support out of the box for WebFlux, Jersey, and Spring-MVC.
As before, JMX remains an option and can be enabled or disabled through configuration.
4.2. Creating Custom Endpoints
The new actuator infrastructure is technology-agnostic. Because of this, the development model has been redesigned from scratch.
The new model also brings greater flexibility and expressiveness.
Let’s see how to create a Fruits endpoint for actuator:
@Endpoint(id = "fruits")
public class FruitsEndpoint {
@ReadOperation
public Map<String, Fruit> fruits() { ... }
@WriteOperation
public void addFruits(@Selector String name, Fruit fruit) { ... }
}
Once we register FruitsEndpoint in our ApplicationContext, it can be exposed as a web endpoint using our chosen technology. We could also expose it via JMX depending on our configuration.
Translating our endpoint to web endpoints, this would result in:
- GET on /application/fruits returning fruits
- POST on /applications/fruits/{a-fruit} handling that fruit which should be included in the payload
There are many more possibilities. We could retrieve more granular data. Also, we could define specific implementations per underlying technology (e.g., JMX vs. Web). For the purpose of the article, we’ll keep it as a simple introduction without getting into too much detail.
4.3. Security in Actuator
In Spring Boot 1.x Actuator defines its own security model. This security model is different from the one used by our application.
This was the root of many pain points when users were trying to refine security.
In 2.x the security configuration should be configured using the same config that the rest of the application uses.
By default, most actuator endpoints are disabled. This is independent of whether Spring Security is in the classpath or not. Beyond status and info, all the other endpoints need to be enabled by the user.
4.4. Other Important Changes
- Most configuration properties are now under management.xxx e.g.: management.endpoints.jmx
- Some endpoints have a new format. e.g.: env, flyway or liquibase
- Predefined endpoint paths are no longer configurable
5. Enhanced Development Experience
5.1. Better Feedback
Spring boot introduced devtools in 1.3.
It takes care of smoothing out typical development issues. For example, caching of view technologies. It also performs automatic restarts and browser live-reloading. Also, it enables us to remote debug apps.
In 2.x when our application gets restarted by devtools a ‘delta’ report will be printed out. This report will point out what changed and the impact it might have on our application.
Let’s say we define a JDBC Datasource overriding the one configured by Spring Boot.
Devtools will indicate that the one autoconfigured is no longer created. It will also point out the cause, an adverse match in @ConditionalOnMissingBean for type javax.sql.DataSource. Devtools will print this report once it performs a restart.
5.2. Breaking Changes
Due to JDK 9 issues, devtools is dropping support for remote debugging through HTTP.
6. Summary
In this article, we covered some of the changes that Spring Boot 2 will bring.
We discussed dependencies and how Java 8 becomes the minimum supported version.
Next, we talked about autoconfiguration. We focused on security among others. We also talked about actuator and the many improvements it has received.
Lastly, we talked about some minor tweaks that happened in the development tools provided.
