Jakarta EE and MicroProfile Alignment: Your Input Is Needed
Since it was announced that Java EE would find new life as Jakarta EE at the Eclipse Foundation, there have been many discussions and questions about the relationship between Jakarta EE and MicroProfile. To help clarify and simplify the relationship, the two communities have joined forces in the Cloud Native for Java (CN4J) Alliance.
The CN4J Alliance has analyzed three different approaches to improve alignment between Jakarta EE and MicroProfile and simplify their use together. The advantages and disadvantages of each option are summarized in this blog post by CN4J community participant, Reza Rahman. The post also includes a link to a short survey where you can choose your preferred alignment option and explain the rationale behind your choice.
I recently spoke with Reza about the need to improve Jakarta EE and MicroProfile alignment and why everyone with an interest in cloud native Java should voice their opinion on the best path forward. Here’s an edited version of our conversation.
Q. What is the current relationship between Jakarta EE and MicroProfile and how did we get to this point?
A. At the moment, Jakarta EE and MicroProfile are complementary, but there are some technology areas where there is overlap and others where the alignment is not clear.
We’re at this point because there was a technology gap a few years ago that had to be filled. Developers needed technologies to accelerate cloud native application development and address the issues that arise when creating microservices architectures. But at the time, Oracle was no longer advancing Java EE.
MicroProfile was created to fill this gap and give developers the technologies they needed. In fact, the existence of MicroProfile was part of the impetus for Oracle to contribute the Java EE technologies to the Eclipse Foundation.
Q. Why is more alignment between Jakarta EE and MicroProfile needed?
A. Jakarta EE and MicroProfile are currently established as separate entities, and it’s causing a lot of confusion. Developers are not sure how the technologies relate to one other, or how the two sets of specifications can be used together. It’s time to resolve this confusion.
Today, Jakarta EE can be used on its own for monolithic applications that are primarily designed for on-premises deployments. You can use Jakarta EE to build cloud native microservices architectures, but having MicroProfile technologies to develop microservices for cloud native applications certainly helps.
Similarly, MicroProfile on its own is not truly self-sufficient. It depends on Jakarta EE technologies such as RESTful web services, JSON binding, bean validation, and dependency injection. Even technologies such as Quarkus and Helidon, which are based on MicroProfile, use more Jakarta EE technologies than MicroProfile requires.
We have two highly co-dependent sets of technologies, hosted at the same open source foundation, with many of the same stakeholders. There is a desire in the ecosystem to see better alignment between Jakarta EE and MicroProfile, and perhaps even convergence at some point.
Q. What is the role of the CN4J Alliance in improving alignment between Jakarta EE and MicroProfile?
A. We want the entire ecosystem to understand how MicroProfile technologies can be used in Jakarta EE — for microservices and cloud native development as well as for on-premises monolithic technologies.
To achieve this goal, we’re trying to make it clearer where Jakarta EE and MicroProfile overlap and where they complement one another. We’re also trying to determine how to clarify and streamline the areas where they do overlap and identify potential areas for convergence.
Q. Why is it important for developers to review the alignment options and complete the survey?
A. It’s in developers’ best interests for Jakarta EE and MicroProfile to be better aligned. Using the technologies will be more straightforward, and it’s more likely they will remain relevant over the long term. This will help developers and enterprises protect their existing investments in Java technologies. It will also help to ensure there’s a serious multivendor and specifications-based alternative to Spring, which means the overall Java ecosystem will remain healthier and more competitive.
Q. What should developers be thinking about as they consider the alignment options?
A. Developers should be thinking about their own ease of use and their own requirements, not about how the technologies are organized, structured, or branded today.
Right now, developers face complexity burdens when using Jakarta EE and MicroProfile:
- Which versions of the specifications work with each other?
- Which namespace should be used?
- What should Maven dependency declarations look like?
- Where should improvements be contributed?
At the end of the day, developers just need the simplest possible solution to the problem they’re trying to solve. As developers review the different alignment options, they should ask themselves which approach is best to minimize the complexity burden and make their life easier.
Q. What’s the best way to get started?
A. Start by reviewing the pros and cons of the three alignment options, then specify your preference in the survey. Please also use the comment box in the survey to explain your preference.
We’re looking for the broadest possible spectrum of input, so we encourage everyone with an interest in cloud native Java to consider the alignment options and join the conversation.
About the Author
