Migrating to Spring Boot 3

Estafet consultants occasionally produce short, practical tech notes designed to help the broader software development community and colleagues. 

If you would like to have a more detailed discussion about any of these areas and/or how Estafet can help your organisation and teams with best practice in improving your SDLC, you are very welcome to contact us at enquiries@estafet.com 

The GA release of Spring Boot 3 in November 2022 was the first major revision of Spring Boot since 2.0 was released more than four and a half years ago.  It is also the first GA version of Spring Boot to provide support for Spring Framework 6 and GraalVM.

Highlights of the release include …

  • A Java 17 baseline with support up to Java 19
  • Support for generating native images with GraalVM
  • Improved observability with Micrometer
  • Support for Jakarta EE 10 with an EE 9 baseline
  • Upgrades to the latest stable versions other Spring projects and many third party libraries
  • Enhanced Log4j2 support with new extensions

See Spring-Boot-3.0-Release-Notes for the complete list.

Spring recommend upgrading to the latest Spring Boot 2.x release before migrating to Spring Boot 3.  See Spring-Boot-3.0-Migration-Guide for full details.

Some potential code changes required to migrate to Spring Boot 3 will come from the move to Java 17.  I thought it would be interesting to see what ChatGPT had to say on the subject so I asked it to “Provide a list of reasons to update to java 17” and it came back with a decent list, highlighting that it was a LTS release (supported until at least 2029 java-se-support-roadmap) and that new Java version generally come with performance, memory management and security improvements.  

For new features it listed sealed classes (JEP 409), pattern matching for switch statements (JEP 406) and new pseudo-random number generators (JEP 356).  For JEPs which might impact existing code, the Applet API is now deprecated for removal JEP 409), the Remote Method Invocation Activation package java.rmi.activation has been removed (JEP 407) and the java.lang.SecurityManager and a number of closely related APIs in the java.lang and java.security packages have been deprecated for removal (JEP 411).

Since Spring Boot 3 has been tested up to Java 19 I also asked ChatGPT about that version of Java and got the response …

“As of my last update in September 2021, Java 19 had not been released, and therefore, I don’t have specifics on the features and improvements that it would bring. However, Java has a history of continuous improvements in terms of performance, security, and new features with every release.”

… which highlights one of the limitations to be aware of when using ChatGPT.  At least in this instance it indicated that it didn’t have the information requested.  The Large Language Model (LLM) technology underpinning these AI systems can exhibit a phenomenon called hallucination where the output matches the expected pattern of the response without actually representing reality or factual information.  A law firm discovered this to their cost when they submitted documents in a court case citing supposed supporting cases which they had used ChatGPT to find.  However there weren’t any, so ChatGPT made up plausible case descriptions complete with references, but which didn’t actually exist (Lawyers who cited fake cases hallucinated by ChatGPT must pay).

The switch from Java EE 8 to Jakarta EE 9 APIs will almost certainly require some code changes although these should be relatively straightforward.  Updating the pom file in a sample Spring Boot project …

… immediately flagged these errors in the persistence and validation packages …

… as these classes are now in the jakarta.* package…

This should also be the case for the following packages …

  • javax.activation.*
  • javax.jms.*
  • javax.json.*
  • javax.mail.*
  • javax.servlet.*
  • javax.transaction.*
  • javax.validation.*
  • javax.websocket.*
  • javax.ws.*
  • javax.xml.*

The only other compilation error related to exception handling.  Methods in the 

org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler class now have a slightly different method signature.  In Spring Boot 2 the http status code was passed as an org.springframework.http.HttpStatus …

It is now passed as a class which implements org.springframework.http.HttpStatusCode  so a small change to the overriding method is required…

The last changes were in third party dependencies which must now support Jakarta EE 9.  In this case I needed to update the SQL Server dependency.  Any libraries which are still being maintained should certainly have a Jakarta compatible version by now.  If not then this is probably a good time to find an alternative.

Looking at the core changes listed in the Spring-Boot-3.0-Migration-Guide one that caught my eye was a change to the default format for the date and time component of log messages for Logback and Log4j2 which has changed to align with the ISO-8601 format. The new default format has a T separating the date and time instead of a space character and adds the timezone offset to the end.  This may be something DevOps need to be aware of for log file processing.

The final step is of course testing.  Hopefully, you have a good set of integration tests to validate your applications.

By Jeremy Gosling, Principal Consultant, Estafet

Stay Informed with Our Newsletter!

Get the latest news, exclusive articles, and updates delivered to your inbox.