Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.
Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.
In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:
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.
