The transition of Java EE to the Eclipse Foundation is now complete with the release of the Jakarta EE 8 Platform Specification and the compatible implementations, including Payara Server. The release plan for Jakarta EE 9 is also approved, and will move all the Java EE APIs to the jakarta namespace – providing a future platform for Jakarta EE 10 and beyond.
Jakarta EE has a clear roadmap and open source future. Attention is now turning to the relationship between Eclipse MicroProfile and Jakarta EE. I won’t go into the history of MicroProfile, but both MicroProfile and Jakarta EE are initiatives at the Eclipse Foundation. Both seek to specify server-side Java APIs for building enterprise applications that can have multiple independent implementations, and both initiatives have many of the same participant organisations.
Co-Existence Between MicroProfile and Jakarta EE
There are a number of views and discussions taking place about co-existence between MicroProfile and Jakarta EE, such as creating relationships between the communities including multiple working groups, and creating a merged cloud-native working group, but I feel they’re missing the logical next step. In this blog, I will put forward a more extreme vision of how collaboration and alignment may occur between MIcroProfile and Jakarta EE. I’m putting this out there as a conversation starter. Do I know this will work? No. Have I worked out all the details and stresses and strains? No. Is this Payara’s preferred option? No. It just feels simple to me for the outside world – and I like simple.
A Radical Vision for Technical Alignment
Here’s a radical option for MicroProfile alignment with Jakarta EE, which is actually pretty simple. All MicroProfile APIs should move to the jakarta namespace when MicroProfile adopts Jakarta EE 9 as a baseline. MicroProfile specifications can then become Jakarta EE specifications. Core MicroProfile APIs should be incorporated into Jakarta EE 10. MicroProfile should become a profile of Jakarta EE in its own right, retaining its existing core API set, alongside Web Profile and Full Profile. This to me, is the logical vision for technical alignment and for unifying the two initiatives. However, if you follow this thought experiment, then I feel there are a number of things that would have to change in Jakarta EE for this to happen – some of which I’ll outline below, but I’m sure there are many other changes that would become necessary.
Profiles as Projects and Brands
MicroProfile has its own brand and mind share, and it also has its own vision of how it fits together as a “platform”. This branding should be retained in Jakarta EE. To achieve this, I think each Profile within the Jakarta EE working group should have its own project team. That team would be the sole custodians as to what makes up the profile, what specs get in, what the specifications in the profile need to do to ensure consistency and coherence within the platform. The team would decide what compatible implementations need to do to certify profile compatibility, what makes up the profile TCK. Each profile would therefore be free to pick which specification under the umbrella it wants to use to define the profile. Some specifications may never be adopted by a profile, but remain as standalone, this is currently true of Jakarta NoSQL, and maybe in the future Eclipse Krazo will become Jakarta MVC.
Deprecation Models
Profiles must specify their deprecation models. For example, suppose the Wombat Specification project team wish to release Wombat 2.0 which is a breaking change from Wombat 1.0. MicroProfile could adopt Wombat 2.0 in their next release, dropping support for Wombat 1.0 in one go. Whereas Full Profile may deprecate Wombat 1.0 support in their next release, mark Wombat 1.0 support optional in their 2nd release, and then fully remove Wombat 1.0 only in the 3rd release. Enabling profiles to define their deprecation rules enables different approaches to backwards compatibility and speed of change. Documenting the deprecation model at the profile level means users of the profile can understand these rules and manage expectations.
Innovation Models and Experimental Specs
Innovation in specifications can happen outside of profiles. Jakarta EE already allows specifications to be proposed, created, and developed before they are adopted in a profile. Products like Payara could continue to adopt those specifications while still supporting MicroProfile, or Web Profile, and then just indicate to customers that they are available but considered tech preview or unstable. Profiles can be free to adopt specifications based on their own criteria and judgement consistent with their stability, deprecation, and backwards compatibility goals.
Application Packaging and Deployment
Currently, Jakarta EE specifies application packaging formats and rules which are incorporated into the platform and individual specifications. These formats may not be appropriate to some runtimes which do not really support traditional deployment models of application servers. However, profiles could adapt these standard deployment formats, dispense with them all together and specify other mechanisms for packaging, or not specify packaging formats at all – depending on the specifications they include and their packaging requirements. Many of the traditional wording in the Jakarta EE specifications oriented around roles including Developer, Deployer, etc. could be removed to make the specifications more supportive of alternative runtime models. For example, MicroProfile is currently silent on how to package an application, and different runtimes do it in different ways.
Release Cadence
Profiles should be able to adopt their own release cadence and I envisage this will typically be a release train model. Each Profile is free to pick the set of specifications and versions that they will include in their profile release. Some profiles may follow a quarterly release cadence, others might follow a 2 year release cadence, it would be their choice. Some may follow a Java SE style approach with LTS releases, and others more experimental releases. Full Profile could be conservative and MicroProfile could be rapid. The Jakarta EE processes could be reviewed to see if we have created something that is a little too heavy for rapid releases, but that is all in the remit of the working group.
The Challenge of Consistency
This idea explained above may sound like a recipe for hugely diverging profiles. If the profiles have nothing in common and radically different ways of developing and building Jakarta EE applications, to the point where the Jakarta EE brand becomes meaningless, then I think it would fall on the Steering and Specification Committees of the Jakarta EE Working Group to ensure a level of consistency for Jakarta EE developers. The consistency would allow them to seamlessly move between profiles using specifications they are familiar with. The Steering and Specification Committees of the Jakarta EE Working Group ultimately sanction the creation of a new Profile and the Release of a Profile. There will always be some tension between project/profile freedom and consistency and coherence of the overall Jakarta EE experience. This tension also exists currently between the desire of individual specification projects to satisfy their ideas and the needs of a profile to remain consistent.
A Technical Alignment Option Worth Exploring
To summarise, I feel a simple technical alignment between MicroProfile and Jakarta EE could be achieved by the MicroProfile APIs joining the Jakarta EE initiative, and adopting the Jakarta EE namespace when they adopt Jakarta 9 as a baseline. I think this is an option that is not currently part of the discussion, but worth exploring and considering amongst the others.
What are your thoughts? Join the conversation with a comment on this blog or in the MicroProfile Forum.
2 minutes
This is really good option to explore and get everyone’s opinion. As web might not need frequent release, microprofile with high frequency and core platform like CDI, servlet can remain fountain with less release. Everything under unified umbrella certainly adds more value to Java eco system.
From a user perspective your proposal makes sense. It offers a good compromise enabling Microprofile to keep its identity and pace of innovation while preserving the consistency of the overall ecosystem. Maybe it puts more effort on the governance but it simplifies things for end-users which is a great benefit to strengthen Jakarta EE and Microprofile adoption. I’m not fully aware of the details of the discussion between the 2 communities but
I think it’s a good baseline.
I’m left with the sense that Jakarta EE as an Eclipse WG is moving very fast. Microprofile has proved nimble and apt at branding.
As a consumer of both Jakarta EE and Microprofile your proposed alignment would seem to make sense.
Would both developer communities be open to this level of cooperation, Steve?
Dennis
Hi Dennis, in my experience many of the individuals work in both MicroProfile and Jakarta EE so I think the level of cooperation could work.
This is interesting, but it actually leads me to propose an alternative that accepts your merge of the MP specs into a new profile, but additionally, splits off MP and the core jakarta dependencies it has into a MP 5.0 that moves streamlined jaxrpc, cdi, etc. into org.microprofile.* subpackages and solidifies MP as an exploratory platform that evolves on its own. The challenge of consistency issue you raise is avoided by making the platforms separate. I feel there are fundamental differences and focus that are necessary to maintain.
I don’t thinking forking CDI and JAX-RS etc. will help anybody tbh.
First, thanks for coming up with an additional proposal. A big concern I have here is governance. As an independent project, MicroProfile has evolved quickly and successfully – a core reason for having this very discussion. Since this discussion has started, I attend the Jakarta Steering Committee meetings wondering how its decisions (and process) would impact MicroProfile. I truly worry that the open source community-natured approach that MicroProfile has built will be lost. My point isn’t that Jakarta (or the steering committee) is bad in any way, it is just different approach to governance. It fits the needs of Jakarta EE. However, I don’t want to lose the innovative spec process approach and unique culture that MicroProfile has created. MicroProfile operates as an open source community, not as a standards organization. I think any kind of shared governance would negatively impact this. I’d like to find a way to address the alignment needs while MicroProfile remains in a standalone working group.
Also, FYI, this does not align with what the Eclipse Foundation prefers. Their CN4J proposal is intended to be much broader than Jakarta EE and MicroProfile. Would be useful to get the Eclipse Foundation’s input on this proposal.
Hi John, I actually have concerns over MicroProfile governance in that it is not formal enough and the open source community style governance can be gamed by large organisations who can obtain large numbers of committers. That works for an open source project but not for something that wants to create standard specifications with a large number of independent implementations. Longer term if the governance is not fixed other implementations may lose interest and drift elsewhere.