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.
