CODEWITHSUNDEEP
springspring-boottomcat
0xiamjosh
0xiamjosh

Reputation: 573

Spring boot 3 - Jakarta and Javax

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)?

Upvotes: 48

Views: 143060

Answers (4)

Phil Webb
Phil Webb

Reputation: 8642

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.

Upvotes: 32

Ondro Mihályi
Ondro Mihályi

Reputation: 7710

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

Upvotes: 4

Bruno Genovese
Bruno Genovese

Reputation: 51

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.

Upvotes: 1

Maik
Maik

Reputation: 433

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.

Upvotes: 0

Related Questions