Spring Boot 3.0 is significant for several reasons - we look at the most noteworthy features of this release.
The Spring Framework has been around a long time now, in fact version 1.0 was released way back in 2004. Over the years it grew and grew with numerous modules now comprising the overall framework. During this time the set up and configuration of Spring applications became both a time consuming and error prone task but also one which contained a lot of boiler plate code and configuration. Back in 2014 Spring Boot was introduced as an opinionated way of automatically configuring and managing Spring applications. The current version Spring Boot 2.0 was first published in February 2018 with the current version 2.7 being launched in May 2022. Support for this version of Spring Boot ends in November 2023 (although commercial support can be extended to February 2025).
The next version of Spring jumps to a new epoch with the release of Spring 3.0 due in November 2022. This version of Spring Boot is significant for several reasons including the fact that it will use Spring Framework 6.0 (where as Spring Boot 2 has used Spring Framework 5.x releases) and it will require Java 17 as a minimum.
In the remainder of this blog we will look at Spring Boot 3.0 and the most noteworthy features of this release.
Java 17 is the latest LTS (Long term Support) version of Java available and represents a significant jump for Spring and Spring Boot. The previous version of Spring / Spring Boot required a minimum Java version of Java 8 (which is also a LTS version). However, with the next release of Spring boot the minimum supported version will jump past Java 11 (the next LTS version after Java 8) and straight to Java 17. This may not be a problem for many organisations but any organisation still using Java 8 or Java 11 will now be forced to migrate if they wish to use Spring Boot 3.0.
Why does Spring now need Java 17, in summary so that the code base can make use of the newer language features available in Java 17. This includes records
as a way of creating more concise data-oriented classes, more sophisticated switch statements as well as things such as sealed classes and interfaces.
A potential breaking change for many project teams will be the adoption of the Jakarta EE9 platform over the old Java EE
version. To understand what is about to happen it is useful to understand what Java E is (or was) and what Jakarta EE 9 is. Both represent am set of specifications and implements that extend Java SE (Standard Edition) for the server side (or enterprise wide) platforms. In both cases EE stands for Enterprise Edition.
Back in 1999 the Java 2 Enterprise Edition (or J2EE) represented the parts of Java that focussed on the backend or service end of an application. In 2006 in effect Java 2 EE was renamed Java EE (or the Java Platform Enterprise Edition) with difference version numbers associated with this name (such as Java EE 6 or Java EE 7).
However, in 2017 Oracle gave away the rights to the Java EE platform to the Eclipse Foundation (although the language remained part of Oracle). At this point the Eclipse Foundation legally had to rename Java EE as Oracle owned the rights to that name. The name Jakarta was chosen by a community vote and thus we end up with the Jakarta EE name for the enterprise edition of the Java platform.
So what? Why is this noteworthy? Unfortunately, there was also a legal tussle over the names of the packages which meant that the Eclipse Foundation could not create any new packages within the javax namespace (although confusingly they could create new classes and subclasses under existing ones!). As a result the Eclipse Foundation renamed all the packages into a Jakarta namespace, thus java.servlet became jakarta.servlet.
The previous version of Spring Boot and the Spring Framework required Java EE 7 as a baseline. However, with Spring Boot 3.0 they have moved over to Jakarta EE9. This means that if any code written by developers or indeed by third party libraries references any interfaces or classes from the EE platform, at a minimum the package names will now need to be changed.
For development teams it means searching their own code for any javax EE references and replacing them with the jakarta equivalent (assuming one exists).
For third party libraries it means checking to see if there is a version of that library available for Spring boot 3.0 that uses Jakarta EE 9 instead of Java EE. It should be noted that for any well managed, well-maintained libraries this should not be a problem as this has been sign posted for some time. However, if a library that is being used is no longer maintained or lacks sufficient resources for that maintenance then this could be a problem.
As with any upgrade there will be some elements of the previous version which may be deprecated in the next version, and this is certainly the case with Spring 6.0 which of course underpins Spring Boot 3.0. In the case of Spring deprecated elements have one release before they are typically removed so there may be a need to address any deprecations as soon as possible.
In addition, Spring Framework 6.0 is not binary compatible with previous versions of Spring and thus all code will need to be recompiled.
Spring Boot 3.0 will support native executables. This feature is based on the Spring Native Initiative which will now become part of the Spring core framework. This feature allows developers to build native executable images that can be deployed to the GraalVM.
The advantage of doing this is faster startUp times and reduced resource (particularly memory) consumption as well as a simpler deployment model.
GraalVM is an alternative to the OpenJDK runtime usually used with java. However, it adds an additional feature – Native Images. This supports AOT (ahead-of-time) compilation.
A native image only includes code that is actually used in an application / program in the runtime environment. To do this the native image generator examines all the source code and determines all reachable code. That is, all code that an application actually uses either directly or indirectly – everything else, whether its application code or part of the Java platform – is excluded. This results in a smaller footprint for the native image.
Observability
is the ability to measure the internal state of a system only using a set of external outputs. That is, information such as the resource consumption of the host system, the log data generated by the application, request traces across a set of services etc. without the need to instrument the underlying code.
Observability is important in a distributed system, including one comprising services or micro services, in helping to identify unexpected or undesirable behaviour or characteristics.
In Spring 6 observability is supported by default by the core modules. In Spring Boot 3 observability is auto configured and underlying Spring projects instrument themselves using Spring’s observation API.
Support is going to be provided to migrate Spring 2.7 projects to Spring 3. However, if you are on an older version of Spring Boot you will first need to migrate your code to Spring 2.7.
You will also need to migrate to Java 17 LTS version (or newer) if you have not already done so.
You should also check that any other 3rd party libraires that you are using have a Java 17 and / or Jakarta compatible version available.
And of course, you should test everything under the new platform.
Spring Boot 3.0 launch is just around the corner. Free support for Spring Boot 2.7 ends in a year’s time in November 2023 so now is the time to look at Spring Boot 3.0 and understand the issues you might face. The full release of Spring Boot 3.0 is due at the end of November but currently you can explore what Spring 3.0 will be like using the 3.0.0 preview
release or the daily snapshot.
If you found this article interesting you might be interested in our the following Courses:
