Spring Update #1 – New Baselines: Java 17 and Jakarta EE
In the last two months of 2022, we saw many new releases from the various Spring teams, most notably the new generations of the Core Spring Framework and Spring Boot, with versions 6 & 3, respectively.
In this 4 part blog series, I’ll provide an overview of the most important new features introduced and explain what’s involved when migrating existing applications to these new versions.
First, we’ll introduce and explore the new baselines of Java and Jakarta EE. Let’s dive in.
New Baselines: Java 17 and Jakarta EE
While publishing two significant releases, the Spring development teams have taken the opportunity to raise some of the minimum requirements. Java 17 has become the new baseline for the supported language version, and the frameworks have switched to the Jakarta EE namespaces.
Spring has supported Java 17 for quite some time already, so if your current code base is still using an older version then upgrading to Java 17 is a sensible first step. Spring 6 supports versions 18 and 19 as well.
Adopting Jakarta EE means that servlet containers, JPA providers, Bean Validation implementations etc. all need to use the “jakarta” packages, where previously the “javax” packages were used. Oracle has transferred custody of the Java EE specifications to the Eclipse Foundation, but in doing so insisted on changing the usages of the javax namespace as that’s limited to Oracle which holds the rights to the Java trademark. With that, Jakarta EE specifications are incompatible with the previous Java EE versions in terms of packages. Apart from that, no other breaking changes were introduced in the initial Jakarta EE releases.
Spring Boot 3 supports both Jakarta EE 9 and 10. The former only really has the package change, the latter actually contains new functionality as offered by e.g. Servlet 6.0 and JPA 3.1.
The dependencies provided by default by Boot 3 have all been upgraded to recent Jakarta-EE compatible ones. Examples are Tomcat and Hibernate ORM & Bean Validator. To start using Hibernate 6 you will probably need to make some changes to existing applications; JBoss has published a migration guide
Your own code will need to start using the new namespaces for its dependencies as well, so you’ll need to perform some migration. This mostly consists of a straightforward search & replace: your IDE or dedicated migration tools can assist you with that. Keep in mind that you’ll need to update your stated dependencies as well, so where you were previously using javax.servlet:javax.servlet-api coordinates, you’d now use jakarta.servlet:jakarta.servlet-api, for example.
For suppliers providing implementations of Enterprise Java standards it’s undoable to keep on supporting releases of their software for both (incompatible) versions of the standards, so it makes a lot of sense that Spring is choosing to switch to Jakarta EE with this new generation of its frameworks.
This does mean that everything that you’re using needs to be Jakarta-EE compatible: also think about tooling like the OpenAPI Generator here, which generates code that uses bean validation annotations! The “spring” generator of this tool currently provides a “useSpringBoot3” option, but not all your tooling might already provide Jakarta-EE support: check this when you’re thinking about upgrading
Final Remarks
Spring Framework 6 and Spring Boot 3 are significant releases with many changes and new features. Although upgrading existing applications requires effort, the process is usually manageable and straightforward. You can make a smooth transition if you ensure that all your dependencies are compatible with Jakarta EE. In the proceeding articles in this series we’ll discuss the benefits that these new versions will bring.
