Your Input Needed to Determine Path for Jakarta EE/MicroProfile Alignment

As you are likely aware, Java EE has transitioned to Open Source governance in the Eclipse Foundation as Jakarta EE. MicroProfile has been moving forward as an independent initiative to optimize enterprise Java for microservices architectures. The Cloud Native for Java (CN4J) Alliance has recently been formed to promote better alignment between Jakarta EE and MicroProfile.

One of the key issues to sort out is how Jakarta EE can consume MicroProfile specifications (such as MicroProfile Configuration). There are several alternatives as to how this could be done. The following is a brief analysis of the advantages and disadvantages of each approach, as discussed in the CN4J community thus far. At the end of the analysis, there is a survey you should weigh in on. In addition to choosing the option you believe to be best, it is very valuable to provide comments justifying your preferred alternative. The results of the survey will be shared with the CN4J community and key decision makers.

Jakarta EE and MicroProfile Context

Both Jakarta EE and MicroProfile produce specifications that are intended for and used in cloud native and microservices use cases. In particular, MicroProfile has a specific focus on meeting the needs of cloud native and microservices use cases. MicroProfile also produces comparatively faster platform releases (roughly once a quarter) while the Jakarta EE release cadence is slower (the likely long term target being approximately once a year).

Jakarta EE currently provides relatively strong guarantees for backward compatibility for all specifications. MicroProfile does not currently guarantee backwards compatibility for all specifications, but does produce production-ready specifications that have demonstrated real world adoption. This characteristic enables MicroProfile to focus on innovation in emerging areas while Jakarta EE focuses on more conservative use-cases and stability best suited to the largest enterprises. While MicroProfile specifications have on occasion needed to break backwards compatibility, this decision is made with due care for end users.

MicroProfile specifications depend on one or more Jakarta EE specifications while Jakarta EE does not currently have any dependencies on MicroProfile.

Option A1: Move MicroProfile specifications to Jakarta EE without changing namespaces (so no need to change namespace from org.eclipse.microprofile.* to jakarta.*). Nonetheless, the Maven coordinates for MicroProfile specifications will move to Jakarta. Further evolution will take place under the Jakarta EE working group.

Pro:

• There is no need for existing MicroProfile users to switch namespaces.
• This gives MicroProfile due credit going forward for bringing a specification into Jakarta EE.
• No API duplication between MicroProfile and Jakarta EE.
• There is only the existing one-way dependency between MicroProfile and Jakarta EE.
• Some users may wish for greater convergence of MicroProfile into Jakarta EE. This option satisfies this desire to some extent.

Con: 

• Lack of namespace consistency for Jakarta EE users otherwise not using MicroProfile.
• Some users may perceive this to mean only Jakarta EE is where production ready specifications are available.
• It is not immediately obvious to a casual user using both Jakarta EE and MicroProfile in the same application which MicroProfile APIs belong to the MicroProfile working group and which MicroProfile specification belongs to the Jakarta EE working group. This may lead to brand confusion for some users as well as mismatched expectations with regards to characteristics such as backwards compatibility and release cadence.

Option A2: Move MicroProfile specifications to Jakarta EE including the namespace. In this case, the namespaces will be changed from org.eclipse.microprofile.* to jakarta.*. Further evolution will take place under the Jakarta EE working group. No more work will be done in the MicroProfile working group to further evolve a specification once it is moved.

Pro: 

• Namespace consistency for Jakarta EE users otherwise not using MicroProfile.
• No API duplication between MicroProfile and Jakarta EE.
• There is only the existing one-way dependency between MicroProfile and Jakarta EE.
• It is immediately obvious to a user using both Jakarta EE and MicroProfile in the same application which specifications belong to the MicroProfile working group and which specifications belong to the Jakarta EE working group. This includes expectations of characteristics such as backwards compatibility and release cadence.
• Some users may wish for greater convergence of MicroProfile into Jakarta EE. This option satisfies this desire to some extent. This may include a possible preference for the jakarta.* namespace, which is more generic – as opposed to the org.eclipse.microprofile namespace, which may imply a focus on microservices.

Con: 

• Existing MicroProfile users will need to switch namespaces in order to take advantage of newer versions of moved specifications. Similarly, implementers will need to put effort towards migration, including potentially maintaining two separate work streams at least in the short term.
• Some users may perceive this to mean only Jakarta EE is where production ready specifications are available.

Option B: Reference MicroProfile specifications in Jakarta EE and not move MicroProfile specifications. Jakarta EE will not duplicate any referenced specifications and MicroProfile specifications will only be evolved under the MicroProfile working group.

Pro:

• No API duplication between MicroProfile and Jakarta EE.
• No migration effort is needed for any users or implementors, while Jakarta EE can still use the specification.
• Some users may wish for MicroProfile and Jakarta EE to remain as separate as possible. This option satisfies this desire to some extent.

Con:

• Lack of namespace consistency for Jakarta EE users otherwise not using MicroProfile.
• It is not immediately obvious to a user using both Jakarta EE and MicroProfile in the same application which MicroProfile specifications are referenced by Jakarta EE and which are not (and as a result have different expectations with regards to characteristics such as backwards compatibility).
• The referenced MicroProfile specification may wish to break backwards compatibility at some point in its evolution while Jakarta EE does not. Additional efforts will need to be made to address such mismatches.
• This introduces a circular dependency between Jakarta EE and MicroProfile. This can make matching release cadences, dependencies, features and collaboration more difficult, including potentially unexpected challenges for end users. The following is one possible example illustrating version dependency mismatches: MicroProfile m2 aligns with Jakarta EE j1, while Jakarta EE j1 aligns with MicroProfile m1. MicroProfile Configuration c2 is included in MicroProfile m2. Jakarta Persistence p1 relies on MicroProfile Configuration c1 in MicroProfile m1 because Jakarta EE j1 was released before MicroProfile m2. An application wants to use both Jakarta EE j1 and MicroProfile m2 together. Which MicroProfile Configuration version will the application end up with? If MicroProfile Configuration c2 in MicroProfile m2 was loaded, Jakarta Persistence p1 may not work with MicroProfile m2 as expected when tested and released via the Jakarta EE j1 compatibility test kit/TCK).
• If Jakarta EE integration specific changes are required in MicroProfile specifications, it will require coordination across working groups in a timely fashion with regards to dependencies, release cadence and features.

Option C: Create Jakarta EE versions of MicroProfile specifications. In this case, Jakarta EE and MicroProfile will develop similar features in parallel.

Pro:

• MicroProfile and Jakarta EE can independently evolve features as they best see fit.
• End users can mix and match MicroProfile and Jakarta EE as they best see fit. Implementations may do the same.

Con: 

• Duplication of effort and resources across Jakarta EE and MicroProfile. The duplication of effort will likely also extend to implementations.
• End users will need to choose between equivalent features in Jakarta EE and MicroProfile.
• MicroProfile and Jakarta EE will very likely be seen as directly competing efforts, leading to further confusion.

Voice Your Opinion!

Each of the alignment approaches have advantages and disadvantages. While decision makers might guess what the right tradeoffs for end users and the ecosystem are, you have a role in providing feedback on what works best for you. Please take a moment to fill out this short survey and provide your feedback now. The results of the survey will be shared with decision makers. You should also continue to stay engaged by subscribing to the CN4J Alliance mailing list.