How to handle "the import cannot be resolved" compilation errors on some javax.* imports while upgrading to Spring Boot 3 and migrating to jakarta.*?

Question

I am upgrading my application from Spring Boot 2 to Spring Boot 3. I am aware that we have to use jakarta.* package instead of javax.*, but I am not sure what to do with among others javax.net.*, javax.sql.* and javax.imageio.* imports. They show compilation errors like below when attempting to swap out javax for jakarta:

The import jakarta.net cannot be resolved
The import jakarta.sql cannot be resolved
The import jakarta.imageio cannot be resolved

What is the correct replacement for these with respect to jakarta.* package? I am not able to find the libraries for javax.net.*, javax.sql.* and javax.imageio.* in Jakarta EE.

Answer 1

I am not able to find the libraries for javax.net.*, javax.sql.* and javax.imageio.* in Jakarta EE.

These are not part of Jakarta EE and have never been part of legacy Java EE either.

These have always been part of Java SE. Open the Java SE package list and Ctrl+F on javax. You'll find the following javax.* packages being part of Java SE:

• javax.accessibility
• javax.annotation.processing
• javax.crypto
• javax.imageio
• javax.lang
• javax.management
• javax.naming
• javax.net
• javax.print
• javax.rmi
• javax.script
• javax.security.auth
• javax.security.cert
• javax.security.sasl
• javax.smartcardio
• javax.sound
• javax.sql
• javax.swing
• javax.tools
• javax.transaction.xa
• javax.xml.catalog
• javax.xml.crypto
• javax.xml.datatype
• javax.xml.namespace
• javax.xml.parsers
• javax.xml.stream
• javax.xml.transform
• javax.xml.validation
• javax.xml.xpath

You can keep them as-is. Just listen to the compiler.

Do note that the javax.annotation, javax.security, javax.transaction and javax.xml have been listed with more specific subpackages, because there are also jakarta.* equivalents on these packages. You can find them in the Jakarta EE package list. For example, JAXB is provided by Jakarta EE via jakarta.xml.bind.

Especially when you happen to also need to upgrade from Java SE 1.8 to Java SE 17 while you use a barebones servletcontainer such as Tomcat instead of a real Jakarta EE server, then JAXB can cause a lot of confusion because JAXB was originally also provided by Java SE runtimes, and is normally also already provided by stock Jakarta EE servers, but not by Tomcat. You basically need to manually install JAXB in Tomcat, or to manually supply it along with the webapp. See also among others JAXB not available on Tomcat 9 and Java 9/10.