What's next for MicroProfile and Jakarta EE?

First, a brief history of the Eclipse MicroProfile project. MicroProfile was created to extend the Enterprise Java environment for developing microservices. We first selected the minimal three Java EE technologies that would provide a solid base for microservices development – CDI, JAX-RS, and JSON-P. Since that initial release, we have added several other component features to further define the microservices programming model. Our latest MicroProfile release has also included support for Java EE 8.

Each component release of MicroProfile is required to create a specification, an API, and a TCK (Test Compatibility Kit). We also require at least one "compatible implementation"---an open-source implementation that successfully implements the specification, uses the API, and passes the TCK. Periodically, these component features are collected into a higher-level, convenience release known as MicroProfile. At this point in time, the MicroProfile "platform" releases do not define additional specifications, APIs, or TCKs.

Let’s talk a bit about the Eclipse Jakarta EE project and its current state of affairs. As stated previously, Jakarta EE is the new home for the Java EE platform. Oracle will continue to own everything associated with Java EE, up to and including Java EE 8. All future development of this Enterprise Java environment after Java EE 8 will be done at Eclipse under the guidance of the Jakarta EE working group. Fantastic progress is being made transferring the Java EE code base to Eclipse under the EE4J top-level project.

Some explanation for naming fans: Jakarta EE is the working group name at Eclipse, while EE4J is the top-level project name for code and materials developed at Eclipse for Jakarta EE. Many times, these two terms could be used synonymously but the brand name we use is Jakarta EE and code in the EE4J projects provide APIs, docs and implementations. It’s intended that there will be multiple independent implementations of Jakarta EE across a variety of open source organizations and projects so the code projects at Eclipse are gathered under a project name, ee4j, that is distinct from the brand name (Jakarta EE).

A couple of things to note with this graphic…​

Beyond the transferring of the code itself, Jakarta EE also needs the Java EE Specifications and TCKs. Java EE (along with the JCP) defined standards for Enterprise Java. In order to develop and maintain these standards, Eclipse must be able to define an appropriate specification process. This effort is owned by the Jakarta EE Specification Committee. An initial draft of the specification process has been distributed for review.

At the same time, the compatibility process needs to be defined in order to protect the Jakarta EE brand. There needs to be some expectations and rules put in place so that only "approved" implementations can proudly display the Jakarta EE logo on their product and web pages. This approval process is tightly coupled with the specification process and is also owned by the Jakarta EE Specification Committee.

Both of these Eclipse projects have merit and are making progress in their respective domains, with MicroProfile technologies building upon those being contributed to Jakarta EE. But are the projects themselves ready to be merged? IMHO, no. MicroProfile has grown tremendously from its humble beginnings. We have several new component features and versions that extend the Enterprise Java programming model for microservices development. And we have done this in a relatively short amount of time: Six major MicroProfile releases with sixteen component releases in less than two years.

Due to the enormity and complexities of this move, Jakarta EE is not yet ready to match this rate of progress. And, as Jakarta EE has not yet completed the definition of its specification process, it is not yet ready to accept the fast-paced release cycle required by MicroProfile. The big difference here is that MicroProfile has never tried to be a standards body. MicroProfile produces industry-accepted specifications, not standards. Jakarta EE is trying to replace the JCP Standards body with a more modern, open, and lightweight implementation-first process.

Until Jakarta EE has demonstrated a specification process that allows the rapid, innovative aspects of the MicroProfile project, MicroProfile will maintain its own project dynamics distinct from the EE4J projects. MicroProfile can continue to iterate quickly in parallel to working with the Jakarta EE platform to adopt completed MicroProfile technologies into the next release of Jakarta EE. Over time, the need for this distinction is likely to reduce, especially as many of the same teams and people are involved with both projects. Yours truly is one of the project leads for the MicroProfile project. I also participate on the EE4J PMC as well as the Jakarta EE Steering and Specification Committees. We are working together to make this happen.

In the meantime, there are a few activities that are demonstrating the coming together of these two projects and technologies…​

In conclusion, I do need to emphasize that this post is my view of where we stand and what needs to be done to better integrate MicroProfile with Jakarta EE. This is not a collective view of the MicroProfile community, although they were made aware of this pending article. I do believe that eventually this merging of MicroProfile and Jakarta EE must and will happen. It’s just a matter of timing.

Kevin is Eclipse MicroProfile co-lead and EE4J PMC member.