| [jakarta.ee-community] Options for Jakarta EE and MP alignment |
|
All, There has been a recent debate on to fork or not to fork MicroProfile Config. I wanted to outline what I feel are the 3 options available to the Jakarta EE community in adopting MicroProfile apis. The last two options are predicated on
the MicroProfile community bootstrapping a working group and putting their apis through a specification process.
Graduate MicroProfile apis into Jakarta EE Specifications In this model Jakarta EE takes relevant MicroProfile apis as inspiration and starts a specification project to move the ideas from the MicroProfile api into the jakarta namespace and create an equivalent Jakarta EE specification that can
be integrated across the platform in a unified and coherent manner. Pros Jakarta EE can pick, choose and adapt ideas from MicroProfile to its needs to ensure consistency across the platform Jakarta EE is free to diverge from the MicroProfile api if it is developing in a direction which Jakarta does not require All Jakarta EE apis are in the same namespace and under control of the Jakarta EE community so can retain backwards compatibility. Any product could be both Jakarta EE version X compliant and MicroProfile version Y compliant.
Cons It requires a move of namespace for the api Developers have 2 apis to choose from if they develop to both the latest MicroProfile and Jakarta EE apis in a runtime that supports both It requires more effort to maintain a potentially diverging api The Jakarta EE Platform Release incorporates a MicroProfile
Platform Release by Reference In this model Jakarta EE version X platform specification could declare it incorporates the entirety of MicroProfile version Y by reference. Pros Jakarta EE is incorporating a well defined MicroProfile platform and can ensure specifications can integrate with it where possible. No move of namespace of MicroProfile apis therefore only 1 api to support and develop to.
A runtime can be both Jakarta EE X compliant and MP Y compliant. Cons An individual runtime will likely be behind the curve on MicroProfile compatibility as it will be difficult to support 2 versions of MicroProfile in the same product version.
It may not be possible for Jakarta EE to retain backwards compatibility across platform releases as MicroProfile allows breaking changes across major versions. Jakarta EE developers are using two namespaces. The MicroProfile api may develop in a direction of no relevance to the Jakarta EE community as they are separate communities.
By referencing a whole MicroProfile platform release the Jakarta EE platform will incorporate apis which may have no relevance to Jakarta EE developers or are not stable.
Jakarta EE incorporates a subset of a MicroProfile platform release In this model a Jakarta EE version X platform specification could cherry pick individual MicroProfile apis for inclusion by reference. For example MP Config X and REST Client Y … Pros Jakarta EE can pick and choose which MicroProfile apis are appropriate. No move of namespace of MicroProfile apis therefore only 1 api to support and develop to.
Cons An individual runtime may not be able to be MicroProfile compliant and Jakarta EE compliant or it will be behind the curve on MicroProfile compliance due to missing apis or conflicting api versions. It may not be possible for Jakarta EE to retain backwards compatibility across platform releases as MicroProfile allows breaking changes across api major versions. Jakarta EE developers are using two namespaces The MicroProfile api may develop in a direction of no relevance to the Jakarta EE community as they are separate communities.
If there are other options feel free to shout and I can develop a doc for comments.
Steve |