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

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 javax
to jakarta
fairly 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.
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 javax
packages to jakarta
, follow the steps below:
- Click the Hamburger menu on top left corner of your project.
- Go to Refactor tab.
- Choose Migrate Packages & Classes option.
- Lastly, click Java EE to Jakarta EE

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.
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:
- https://www.baeldung.com/spring-security-migrate-5-to-6
- https://docs.spring.io/spring-security/reference/6.0/migration/index.html
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
- https://thorben-janssen.com/sequence-naming-strategies-in-hibernate-6/
- https://www.baeldung.com/spring-security-migrate-5-to-6
- https://docs.spring.io/spring-security/reference/6.0/migration/index.html
- https://github.com/hibernate/hibernate-orm/blob/main/dialects.adoc#community-dialects
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.
- If you like the article, please consider clapping and following.
- Star GitHub repository
- Follow me on LinkedIn | X (Twitter) | GitHub
- Check out my other stories.