Upgrade Java Application from version 8 to 17

In this article, I will try to explain my experience in migration the Spring Boot 2.x project that I have been working on recently to Spring Boot 3.x.

For upgrading your Java Spring Boot based application from version 8 to 17 we have to do know few things before to achieve complete migrations successful.

First thing before doing the migration is to upgrade all your latest dependencies/plugins to the latest one and add version of the dependency only in case its not there in spring-boot latest version inside your pom file if its maven project.

Regarding Maven plugin >> We can optionally add the versions-maven-plugin (which will then require maven-enforcer-plugin also) to help with this. It has various things you can run that lets you see what versions of stuff you are using have newer versions, and what those newer versions are. See here:?https://www.mojohaus.org/versions/versions-maven-plugin/index.html

and make sure that?mvn clean install site?works .

Java 17 >> You got a lot of security updations and also new cool features which exist since Java version 9 for the application developers and i am not going to explain in details but can name them.

1. Jshell
2. Local variable type in front using the var keywords.
3. Http clients
4. Switch Expression
5. Text blocks
6. Records
7. Sealed classes.

Jakarta EE >> When we talk about Spring Boot 3 we are using Tomcat 9 and 10.1.1 at different places. Goal of this change is to provide a set of EE 10 providers in spring boot 3. Spring Data now compiles against Jakarta EE10 and the jakarta. packages instead of javax. In short you have to change the namespace in your Entity classes like from java.persistence to jakarta.persistence.

Spring Data 2022 Changes >> Spring Boot 3 use Spring Data version 2022 Spring Data now requires Java 17 as a baseline .So from the below image we can see that now findAll is returning Iterable interface and in older version of java it is returning List so for this now in latest version of Java we do have new CRUD Repositories (like ListCrudRepository) which extends CrudRepository itself but returns a List<T> now.

Sorting repositories no longer inherit from CRUD repositories>> PagingAndSortingRepository no longer extends CrudRepository.

ClientHttpResponse Interface >> In the older version of Java ClientHttpResponse.getStatusCode() used to return HttpStatus. Spring unfortunately decided to change that in a non-backward compatible way by having it instead return a new interface, HttpStatusCode, of which now HttpStatus implements.?And also getRawStatusCode() method is depricated so if we are doing migration then we can't remove this method because we never know our caller application uses old or new version so we need some common method for the backward compatibility.

Observability >> Is the ability to observe the internal state of the running system from the outside world(like we do have multiple tracing application for example Data Dog , Grafana) . This consist of basically 3 pillars?: logging , metrics and traces . For metrics and traces spring boot uses micrometer observation .Distributed traces now wrapped up into micrometer whereas in the past we might reach or depends on the third party library like Sleuth and one interesting thing is if we add dependency(micrometer-registry-statsd) then we got all tracing by default. Example below >

Statsd?- as mentioned, Micrometer is a facade, and Statsd is the implementation we’re going to use. It deals with collecting and sending measurements to a dedicated backend service.

Problem Details: For Http API's > Common requirements of Rest services to include details in the body of an error response Spring Framework suggest and supports the ProblemDetails for Http API's specifications.

Junit Changes>> If, however, your project is still using JUnit 4, and you’re seeing compilation errors such as?java: package org.junit does not exist, it’s because the vintage engine was removed. The vintage engine is responsible for running JUnit 4 tests alongside JUnit 5 tests. If you cannot migrate your tests, add the following dependency to your pom:

<dependency>

<groupId>org.junit.vintage</groupId>

<artifactId>junit-vintage-engine</artifactId>

<scope>test</scope>

</dependency>

Spring Security changes >> Spring security 6 has removed WebSecurityConfigurerAdaptor class. Now we need component based model of declaring beans in the configuration like below >

GralVM Native Images >> GralVM Native Images provides a new way to deploy and run Java applications . As compared to the java virtual machine , native images can run with a smaller memory footprint and with much faster startup times. Spring boot 3 applications now can be converted into a Gram Vm native images which can provides significant memory and start up performance.

Use Case : When should I use native images? Like we have serverless function , cloud native development dependencies on what the workload is we can use native images.If we upload our GramVM image onto the cloud then it saves lot of memory and startup time.

Build the native image and push to provider like AWS/Azure/Google Cloud now you have smaller footprint and this image that can start up very very fast as its native executable.

Docker Compose?- A new module?spring-boot-docker-compose?provides integration with Docker Compose. When your app is starting up, the Docker Compose integration will look for a configuration file in the current working directory. No more starting your application only to see an error because you forgot to run?docker compose up.