Spring boot 3 - Jakarta and Javax

Question

In the new Spring boot 3 Release notes, They tells that this version is going to use Jakarta EE 9 (libs named as jakarta) instead of JEE (libs named as javax).

They advise developers to replace imported javax with jakarta in this article.

If I have a spring boot app with both, javax and jakarta libs, will the app work and be able to be deployed in a Jakarta compatible server (e.g. Tomcat 10)?

Thanks a lot.

Waterproof

Answer 1

The answer will really depend on which specific libraries you're using and how they interact with each other, but generally speaking, trying to mix Java EE and Jakarta EE would be a bad idea.

As an example, if you're writing a Spring MVC application, you'll be using DispatcherServlet. In Spring Framework 6, this will require the Jakarta Servlet API. There's not going to be a way to make it work with javax.servlet. For other APIs, if you're using them directly and you're not making use of Spring abstractions that build on them, you may get away with having them on your classpath. I still wouldn't recommend it.

Sparhawk

Thanks a lot. Actually we got some internal libraries they use javax. They only way to stick with spring boot 3 and jakarta is to migrate all these libs + the main app to Jakarta. – Waterproof

@Phil Webb jakarta.persistence-api does not appear to have a replacement for javax.sql.DataSource or javax.persistence.EntityManagerFactory. Do you know how to address this? – Genie

@BradleyD javax.sql.DataSource is part of the JDK and still uses the javax package. ` jakarta.persistence-api-3.1.0` contains jakarta.persistence.EntityManagerFactory. – Sparhawk

@Phil Webb Once I removed the JPAConfig class, removed all unnecessary dependencies one by one, and added the following to application.properties, i was good to go! spring.datasource.url=${jdbc.url} spring.datasource.username=${jdbc.username} spring.datasource.password=${jdbc.password} spring.datasource.driverClassName=${jdbc.driverClassName} – Genie

@Phil Webb there is lot of changes in Jakarta. I am facing lot of problem after this upgrade. Example I am using 3 entity classes one is parent entity and other two are child for parent. When Using many to one annotations and Saving values to child entity also.. But the foreign key from parent entity is not reflected in child entity . However I tried many way till its not working.. Any one knows solution for it update me... – Lanthorn

Answer 2

When upgrading to SpringBoot 3, Tomcat 10 or anything that requires Jakarta EE 9, it’s always safer to replace all javax dependencies with jakarta ones. It’s not completely straightforward but you can automate it with Eclipse Transformer or similar tools.

If your application compiles OK, then I recommend running the final JAR or WAR through the Transformer. I explain how to do it in this blog: Upgrade To Jakarta EE 10: Transform Applications With Eclipse Transformer

Complaisant

Answer 3

I just migrated my application from spring boot version 2.7.4 to 3.2.1. (Disclaimer: Had to put in a few hacks). From my personal experience, I can say that it's technically possible to have both javax and jakarta libs in a Spring Boot 3 app, however, it's strongly discouraged for the following reasons:

1. Compatibility Issues:

   • Class Loading Conflicts: Having both sets of classes in the classpath can lead to conflicts and unpredictable behavior, as classes with the same name but different package names might clash.
   • API Incompatibilities: Jakarta EE 9 introduces some API changes that aren't compatible with older Java EE APIs. Using both simultaneously can create unexpected errors.
   • Third-Party Library Issues: Some third-party libraries might not be compatible with Jakarta EE 9 yet, and mixing them with jakarta libs could cause issues.

2. Deployment Challenges:

   • Jakarta-Compatible Servers: Servers like Tomcat 10 are designed for Jakarta EE 9, and relying on javax libs might lead to deployment errors or unexpected behavior.
   • Class Loading Isolation: Separating javax and jakarta libs within the server might not be straightforward, potentially causing conflicts.

Recommendations:

• Full Migration:

  • It's highly recommended to fully migrate your application to Jakarta EE 9 to ensure compatibility and avoid potential issues. This involves:
    • Updating Spring Boot to version 3.
    • Updating dependencies to Jakarta EE 9 versions.
    • Refactoring code to use jakarta package names.

• Temporary Workaround:

  • If full migration isn't immediately feasible, consider:
    • Using Spring Boot 2.7 as a temporary solution, as it supports both javax and jakarta APIs.
    • Selectively updating dependencies to Jakarta EE 9 versions where possible, while keeping those without Jakarta-compatible versions on javax.

Important Considerations:

• Thorough Testing: If you choose to mix javax and jakarta libs, conduct thorough testing to identify potential compatibility issues early on.
• Dependency Management: Carefully manage dependencies to ensure correct versions and avoid conflicts.
• Third-Party Library Updates: Stay updated on third-party library compatibility with Jakarta EE 9 to plan future migration steps.

Ultimately, the goal should be to fully migrate to Jakarta EE 9 for long-term compatibility, stability, and alignment with the latest Spring Boot standards.

For Spring v2 to v3 migration, this official guide may be helpful https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide

Wayzgoose

This is helpful. A lot of information. what do you mean by "Had to put in a few hacks"? can you share some examples? – Minny

In SB v3, few things have changed and may not work out of the box they used to work with spring boot 2. For example, some of the in-house developed spring starters still declared spring.factories in old fashion. So either you update the starter to have spring.factories defined the new way or import the configurations manually by using annotation @Import(Config.class). More details about spring.factories are available in this article #75044804 – Wayzgoose

The above one is the most frequently faced issue while migrating to SB 3. but there were other similar hacks I had to put in to make it work. BTW just FYI, I am using Java 17 and some of the in-house libraries didn't have the proper module structure. I had to export the modules in JVM arguments. I hope this helps – Wayzgoose

ok. that makes sense. any other potential issue I should be worried about before starting the migration from jakarta-javax perspective? – Minny

Not that I am aware of. I've already listed above all the pointers I could think of – Wayzgoose

Answer 4

In case it helps anyone, I can confirm the issue.

To deal with security vulnerabilities I updated my POMs from Spring 5.3.15 to 6.0.6 and Spring Security 5.6.1 to 6.0.2.

The very first issue I found was that HttpServletRequest is no longer compatible, at least if you are extending AbstractAuthenticationProcessingFilter and probably much more.

Base on this and other threads it very much seems that the solution is to replace javax.servlet-api with jakarta.servlet-api and update all of the impacted imports.

Deration

Answer 5

You could try to put the web app instead of in webapps into webapps-javaee like described in https://tomcat.apache.org/migration-10.html#Specification_APIs

Then TC10 will create a new war in webapps and unpack it as usual in webapps. I tried it with some of our pure TC8/9 Apps and it was working.

Scarecrow