1. Overview
In this tutorial, we’ll understand why Jakarta EE became the successor to Java EE and learn how to migrate to it.
2. The Genesis of Jakarta EE
Java EE (Java Platform, Enterprise Edition) is a set of specifications first introduced in December 1999 by Sun Microsystems to extend the Java language for traditional enterprise workloads. Oracle then bought Sun in 2009. In 2017, Oracle decided to move the development of Java EE to the Eclipse Foundation, a nonprofit organization known for fostering open-source projects. However, Oracle remains the owner of the Java trademark. Thus, a community vote led to renaming the project to Jakarta EE.
3. Why Migrate to Jakarta EE?
First of all, after the responsibility transfer to the Eclipse Foundation, the original Java EE technology doesn’t receive any new updates, features, or improvements. Thus, in a permanently evolving industry, we can leverage new development paradigms with Jakarta EE. For instance, better microservice support and cloud-native application development were the first focuses of the Eclipse Foundation.
Additionally, migrating grants us long-term support for our application. Furthermore, most vendors and application servers have already transitioned to support Jakarta EE.
Lastly, we might have to migrate during a framework version upgrade. In particular, if we develop a web application with Spring, we’ll need to migrate to Jakarta EE to benefit from version 3.
4. How to Migrate From Java EE to Jakarta EE
We’ll start by migrating our own code. We’ll take care of external dependencies afterward. Last but not least, we’ll make sure we run our application on a compatible tool.
4.1. Application Code
At first glance, migrating from Java EE to Jakarta EE is a refactor to use the jakarta namespace instead of the javax namespace. We need to change the references not only in our class imports but also in our pom files, configuration files, etc.
In reality, the change is a bit more complicated than just a find/replace action. Some javax packages remain outside Jakarta EE and are therefore unaffected by the change. An exhaustive list of unaffected packages is available on the Jakarta EE GitHub.
In a nutshell, this task is repetitive and can pose unexpected difficulties, making it a perfect target for automation. In particular, if we use IntelliJ IDEA, we can open the Refactor menu and then click Migrate Packages and Classes. After that, we can choose Java EE to Jakarta EE and then click Run to have all the relevant imports updated automatically.
Other automation options include using OpenRewrite, an automated code refactoring tool that helps perform large-scale code transformations. In particular, the Jakarta EE migration tool is available in their documentation.
Similarly, we can use the Eclipse Transformer tool for a smooth migration. Originally, this tool targeted our problem specifically. Later, it widened its horizons by addressing general shading issues. Both tools can be used via the command line or through Maven.
4.2. Dealing With External Libraries
The migration can become trickier when dealing with external libraries since we can’t modify the code we don’t own as we wish. The good news is that most Open Source libraries have already migrated toward Jakarta EE. In this case, we only need to use the new version of the library. Some upgraded to a new major version, whereas others moved their repository location.
The situation becomes more epic when such updated version doesn’t exist. In such a situation, evaluating if we want to get rid of the dependency in favor of a more up-to-date one is certainly a question we should ask ourselves. Nevertheless, sometimes, we don’t want this situation to stop us from upgrading to Jakarta EE.
If we get to the unfortunate point that we have a legacy dependency using Java EE libraries and can’t do anything about it but still want to migrate, there is a solution. We can transform the library source code to upgrade it to Jakarta EE. Once again, Eclipse Transformer and OpenRewrite tools are designed to rewrite byte code on the fly to cope with the migration.
Additionally, if we use Tomcat as an application server, the Apache Foundation offers a dedicated migration tool.
To conclude, it’s important to note that mixing jakarta and javax dependencies in the same application isn’t recommended, as it can lead to namespace collisions and other unexpected issues.
4.3. Using an Adequate Server
Servers provide an environment to run and manage our applications. In particular, they include the javax libraries. That’s why we generally mark them as provided in our pom files. Thus, we need an upgraded server version that can cope with Jakarta EE. The Jakarta EE team maintains a compatibility page for that purpose. This page lists all the tools certified to work with Jakarta EE.
5. Conclusion
In this article, we recalled that the responsibility transfer from Oracle to the Eclipse Foundation entailed the name change to Jakarta EE. We also learned it’s a good idea to migrate to keep our applications up-to-date. We saw that the migration isn’t as easy as it initially looks. Hence, we looked at a couple of tools to automate the migration.
Given that we can run those tools through the command line or via Maven, we have various options when addressing non-migrated dependencies, like publishing updated artifacts of external libraries on our repositories or running the migration tool automatically on every build.