You're reading for free via Mammad Yahyayev's Friend Link. Become a member to access the best of Medium.

Member-only story

Challenges for Spring Boot Migration Journey from 2 to 3

Mammad Yahyayev
4 min readAug 12, 2024

My articles are open to everyone; non-member readers can read the full article by clicking this link.

Hello developers. Welcome to my new article. In today’s article, I am going to share my Spring Boot upgrade journey from 2.6.4 to 3.2.3 with you. Let’s begin directly with the first challenge.

Challenge #1: Gradle Wrapper Version

I don’t remember exactly which version I was using with Spring Boot 2.6.4, however, when you upgrade to Spring Boot 3.2.3, you have to upgrade Gradle Wrapper version as well.

Use following command to update Gradle Wrapper version.

./gradlew wrapper - gradle-version <version>

You don’t need to worry about the version, because when you execute the Gradle Wrapper, it will tell you to upgrade Gradle Wrapper to specific version.

It is highly recommended to use Wrapper versions of build tools which brings flexibility and convenience for developers.

If you are using Maven, refer to this article for further information.

Challenge #2: Javax to Jakarta

When you upgrade to Spring Boot 3.2.3. All packages that starts with `javax` will give you compile error because all of them are renamed to `jakarta`.

You can read the reason from StackOverFlow website.

If you have small project, moving from javaxto jakartafairly easy compared to large complex projects. In order to complete the process, you can use 2 approaches.

Approach #1: Shell Script

When I am browsing on the Internet, I came across to a Shell Script which is used to replace all package names at once for your project. This is nice, because you can execute script with a blink of an eye. However, the sad news is this script is not complete. There are not every javax package names to replace, so you should add your owns.

How to replace javax packages with jakarta by using Shell Script?

Script file copied from this link and added to GitHub Gists. If you have any update, feel free to add them as a comment, so I will update the script.

Approach #2: Intellij IDEA

First approach is great if you are using IDE other than Intellij. Intellij IDEA proved itself once again in this context as well why it is a powerful Java IDE.

If you want to convert all of your javaxpackages to jakarta, follow the steps below:

  1. Click the Hamburger menu on top left corner of your project.
  2. Go to Refactor tab.
  3. Choose Migrate Packages & Classes option.
  4. Lastly, click Java EE to Jakarta EE
Converting from Java EE to Jakarta EE in Intellij IDEA

Challenge #3: QueryDSL

I am using QueryDSL to generate dynamic SQL queries based on different criterias.

Setting up QueryDSL in multi module Gradle project took quite a bit of time. Finally, I found the correct dependencies and their versions to use QueryDSL.

QueryDSL dependency

Challenge #4: Spring Security

During the upgrade, Spring Security API has changed in a few places especially inside a class where we define our security configurations.

There will be compile time errors, however you can easily fix them by yourself. You can find lots of materials on the Internet for migration. Here are a few of them:

Challenge #5: Error: Schema-validation: missing sequence

Above error is occurred because when upgrading to Spring Boot 3.2.3, Hibernate version is also upgraded to Hibernate 6.x.

Default naming strategy has changed when migrate to Hibernate 6. Due to that, Hibernate might try using a sequence that doesn’t exist in your database.

Since Hibernate 6, you can use the configuration property hibernate.id.db_structure_naming_strategy to define naming strategy.

However it is recommended to explicitly define sequence names.

🔗 Further info: https://thorben-janssen.com/sequence-naming-strategies-in-hibernate-6/

Challenge #6: Hibernate Dialects

After Hibernate 6.0 version, Hibernate team decided to remove older dialects and only support the new ones. I haven’t seen problem in Postgres DB during upgrade, but in one of the projects, Oracle DB was used and it started to fail in some queries.

In my case, it was existBy query in Spring Data. I did my research and find out, Hibernate moved the old removed dialects to another library called hibernate-community-dialects .

When you face this issue, add following dependency into your build file.

dependencies {
implementation 'org.hibernate.orm:hibernate-community-dialects:6.0.0.Final'
}

// or

<dependency>
<groupId>org.hibernate.orm</groupId>
<artifactId>hibernate-community-dialects</artifactId>
<version>6.0.0.Final</version>
</dependency>

After adding this dependency, you have to update your database platform in application file as well.

spring:
jpa:
open-in-view: false
show-sql: true
properties:
hibernate:
default_schema: ${FLEXCUBE_DB_SCHEMA:MSUSER}
hibernate:
ddl-auto: none
database-platform: org.hibernate.community.dialect.<your dialect>

In my project, it was org.hibernate.community.dialect.Oracle10gDialect.

🔗 Further info: https://github.com/hibernate/hibernate-orm/blob/main/dialects.adoc#community-dialects

References

Conclusion

That’s it for this migration journey. If you have larger application, probably it will need more changes. In my case, there were one or two lines of changes because of the migration, however I decide to not include them because they can easily solved.

Recommended Reading

Mammad Yahyayev
Mammad Yahyayev

Written by Mammad Yahyayev

I am a Software Engineer with 4 years of work experience. I love to share my ideas, knowledge with everybody. Follow me to stay updated on the latest trends.

No responses yet

Write a response