I've been building an API server using the Jersey 3 library. Even after writing the code and calling the correct URL, I kept getting a 404 error.

I wrote a simple test servlet and compared it against the official documentation over and over, but couldn't find anything unusual.

It turned out that Jersey 3 supports Servlet 5.0, and Servlet 5.0 spec can only run on Tomcat 10 or higher, which implements that spec — something I hadn't known until then.

I never paid much attention to the Tomcat version before, but this made me realize there's a big difference between Tomcat 9 and Tomcat 10.

Between Tomcat 9 and Tomcat 10, the API implementation changes completely.

• JavaEE - applies up through Tomcat 9 (javax.*)
• JakartaEE - applies from Tomcat 10 onward (jakarta.*)

Up through Tomcat 9, the same JavaEE spec was implemented. Thanks to this, upgrading the Tomcat version didn't cause any real issues with using JavaEE, thanks to backward compatibility.

However, starting from Tomcat 10, the spec was completely changed to JakartaEE, making it no longer compatible. Since Servlet 5.0 is only supported starting with JakartaEE, running a servlet of that version on JavaEE, or running a lower-version servlet on JakartaEE, causes the servlet to malfunction and produce a 404 error.

Internally and structurally a lot may have changed, but on the surface, the difference between JavaEE and JakartaEE is the package name.

Migration is possible just by changing javax.* to jakarta.*. Below is a summary of the packages for JavaEE and JakartaEE.

As shown above, it's split into javax or jakarta depending on the EE name.

This is also mentioned on the Tomcat 10 download page. Unfortunately, in Korea, the language barrier makes it easy to miss this unless you read carefully.

Actually, this kind of overall structural change isn't common. It's usually only changed after careful discussion and consensus, when there's a critical issue that would have a major impact if left unaddressed, or one that's clearly anticipated. This is especially true for something with a worldwide user base and service scale like Java.

Nevertheless, the reason the package name was changed has more to do with so-called grown-up matters than with technical reasons.

In 2010, when Oracle acquired Sun Microsystems, the developer of Java, the related licenses were all transferred to Oracle. Seven years later, Oracle transferred Java's license to the Eclipse Foundation.

In this process, while Java's license was transferred, Oracle still owns the Java trademark, resulting in the awkward situation where the Eclipse Foundation could not name the Java used in JavaEE as "Java." It's like the American version of Hong Gil-dong (unable to call his own father "father"). You can find the detailed story on the Eclipse Foundation blog.

That's why, in order to comply with the licensing restrictions caused by JavaEE, the Eclipse Foundation changed the name to JakartaEE and has operated under that name ever since. From now on, everything the Eclipse Foundation develops will be reflected in JakartaEE.

JavaEE releases have effectively ended. It's not out of the question that, in a few years, JavaEE could be deprecated and no longer used.

Due to the differences between Tomcat 9 and 10, a WAR compiled using JavaEE cannot be used as-is. This is especially awkward when you must use a third-party WAR, since you didn't compile it yourself and can't easily change its structure.

However, as mentioned above, since migration between JavaEE and JakartaEE is very simple, you can use the following method to easily convert a WAR compiled with JavaEE into JakartaEE.

1. Create a webapps-javaee folder in the Tomcat 10 path.
2. Place the WAR you want to convert into webapps-javaee.
3. Wait for Tomcat to convert it.
   1. If it doesn't convert, restart Tomcat.
4. You can find the converted WAR in webapps.

You can also find this described in the Tomcat 10 release notes on the official Tomcat homepage.

This way, converting from JavaEE to JakartaEE is possible. Whether the reverse is also possible isn't documented anywhere.