It's time to get ready for Spring Boot 3.0

On February 28, 2018 Spring Boot enters the 2.0 era, more than 4 years ago. in November 2022 Spring Boot 3.0 will be officially released, it will be based on Spring Framework 6.0 and will require Java 17 or higher, and it will be the first Spring for Jakarta EE 9 Boot version for Jakarta EE 9. There are still six months left for developers to transition to Spring Boot 3.0, and this article will show you some ways to quickly migrate to 3.0 in the future.

Java 17

Java 17 will be the most important LTS release since Java 8 and is the result of eight years of effort by the Java community. Containing many important improvements, Java 17 is also the most powerful LTS release available. All current Spring Boot 2.x releases are well adapted to Java 17, so you don’t have to wait to start debugging the JDK upgrade and trying out some of the new features and APIs.

Upgrade to Spring Boot 2.7 as soon as possible

Spring Boot 2.7 is basically the last major release of Spring Boot 2.x. Spring Boot 2.5 has stopped OSS support and is no longer maintained, Spring Boot 2.6 will also stop being maintained after the release of Spring Boot 3.0, and the iteration is getting faster and faster. It is advisable to upgrade to 2.7 as early as possible to better migrate to 3.0, and not to jump versions, for example, not directly from 2.4 to 2.7, but try to follow steps like 2.4, 2.5, 2.6, 2.7. Too large a span is not conducive to a smooth upgrade.

Removing deprecated code

Every Spring Boot release has more or less code marked as @Deprecated, Spring Boot 3.0 will completely remove code that is deprecated in 2.x. Of course, deprecated code from early 2.x may also be removed in the latest 2.x. Try not to use deprecated code, which is usually commented with the reason for the deprecation or an alternative API.

Configuration file mechanism changes

In Spring Boot 2.4, the loading mechanism of configuration files application.properties and application.yaml was changed to simplify the way external configuration is loaded and make it more logical, bringing no backward compatibility. In order to smooth the upgrade, Spring provides a configuration item to be compatible with the old mechanism.

1
2
3

spring:
  config:
    use-legacy-processing: true

And this mechanism will be removed in 3.0, we must use the configuration method that conforms to the new mechanism, if you exist these ways need to pay attention.

Multi-document Yaml

If you use the spacer -- in your yaml configuration file to declare multiple documents, you need to know that declared configuration properties are now registered in the order they are declared in the document; in Spring Boot 2.3 and earlier, the order of activation is based on the configuration file. As an example.

---
spring:
  profiles: 
    active: dev
  application:
    name: dev-app
server:
  port: 8081      
---
spring:
  profiles:
    active: prod
  application:
    name: prod-app
server:
  port: 8080

This configuration file in Spring Boot 2.3 and earlier determines the environment to be loaded based on spring.profiles.active. But from 2.4 onwards the later properties will override the earlier ones.

External configuration always overrides the configuration inside the jar

If your configuration file is outside the jar and the configuration file applies to a specific environment, such as application-dev.yaml. In versions below 2.4, application.yaml outside the jar will not overwrite the application-<profile name>.yaml in the jar. file, from 2.4 onwards external files will always overwrite the profile inside the jar. You need to check if this is the case for you.

Activate profiles

If you used the spring.profiles property to activate the environment configuration, you should now migrate to spring.config.activate.on-profile.

Old usage.

1
2
3

spring:
  profiles: "prod"
secret: "production-password"

New usage.

spring:
  config:
    activate:
      on-profile: "prod"
secret: "production-password"

This is a real toss-up. spring.profiles.active can still be used to activate specific environments, e.g. command line.

`1`	`$ java -jar myapp.jar --spring.profiles.active=prod`

You can also use spring.profiles.active in application.properties or application.yaml, but as of 2.4 spring.profiles.active cannot be used in a specific environment, i.e. application-<profile>.yaml, nor can it be used in multiple documents separated by ---. In a nutshell, you can no longer use spring.profiles.active to merge a profile that contains the spring.config.activate.on-profile property.

By the same mechanism, the spring.profiles.include property can only be used in non-specific configuration files, and the following configuration is invalid.

# 无效配置
spring:
  config:
    activate:
      on-profile: "prod"
  profiles:
    include: "metrics"

For more points, please refer to the official documentation: Spring Boot Config Data Migration Guide.

A higher performance path parsing approach

Starting with Spring Boot 2.6, path parsing uses PathPatternParser by default, replacing the previous Ant-style matching AntPathMatcher. After the upgrade, people using Swagger started up with the following exception.

Caused by: java.lang.NullPointerException: Cannot invoke "org.springframework.web.servlet.mvc.condition.PatternsRequestCondition.getPatterns()" because "this.condition" is null
 at springfox.documentation.spring.web.WebMvcPatternsRequestConditionWrapper.getPatterns(WebMvcPatternsRequestConditionWrapper.java:56) ~[springfox-spring-webmvc-3.0.0.jar:3.0.0]
 at springfox.documentation.RequestHandler.sortedPaths(RequestHandler.java:113) ~[springfox-core-3.0.0.jar:3.0.0]
 at springfox.documentation.spi.service.contexts.Orderings.lambda$byPatternsCondition$3(Orderings.java:89) ~[springfox-spi-3.0.0.jar:3.0.0]
 at java.base/java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:473) ~[na:na]
 at java.base/java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) ~[na:na]
 at java.base/java.util.TimSort.sort(TimSort.java:220) ~[na:na]
 ...

This was resolved with the configuration item spring.mvc.pathmatch.matching-strategy=ant_path_matcher. While AntPathMatcher will continue to work in Spring Boot 3.0, PathPatternParser is the official recommendation because of its higher performance, and I’ll have a feature on PathPatternParser later on.

Compatibility issues

The first issue is Jakarta EE 9 compatibility, make sure your third party dependency libraries and your code are compatible with Jakarta EE 9. Also check if any of the third party dependency jars being used by the Spring Framework are planned to be compatible with Spring 6.

Try to learn Spring 6

Spring 6 and Spring Boot 3 have been released with multiple milestones, so take some time in your free time to try them out, experience the new features and changes, and evaluate the difficulty of upgrading your application.

Reference https://mp.weixin.qq.com/s/_P7ilRLR3zscobb5-ZpyCQ

Table of Contents