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. These alternatives were put into a survey for the community to weigh in. In addition to choosing the option respondents believe to be best, they were able to provide comments justifying their preferred alternative. The results of the survey are summarized here. The results have been shared with the CN4J community and key decision makers.
Survey Results
More than 200 people filled out the survey. Even more remarkably, there were more than 50 comments representing the voice of the community. A fairly strong majority (57.73%) of developers want some MicroProfile specifications to move to Jakarta EE including the namespace.
The results are similar to what earlier surveys have indicated and congruent with the official Jakarta EE Ambassadors joint position. It is remarkable how consistent the community view has been, even over a period of time.
The Voice of the Community
It is impossible to do justice to all the people that provided comments. Each one of the comments is invaluable. The following is a decent sampling representing the majority opinion.
“MicroProfile should evolve APIs that eventually get absorbed by Jakarta EE. MicroProfile applications should eventually be able to run with pure Jakarta EE APIs.”
“Moving MicroProfile specs into Jakarta EE including namespace will make clear where the longer term specs are maintained. Also, for MicroProfile users it’s a very easy migration path.”
“I think no matter which of these options is chosen there is going to be an effect on either end users, or developers. Therefore, I would rather make the large upfront breaking changes all at once and merge the two into the same namespace. Then, have consistency going forward.”
“I would see the movement from org.eclipse.microprofile to the jakarta namespace as a sign of maturity (and success) for MicroProfile.”
“Option A2 has fewer cons and is more end user friendly.”
“Using a different namespace makes it clear what version and expectations (e.g. backward compatibility) the user is making. Moving without a namespace is confusing.”
“The aim of a specification should always be to make something as simple and clear as possible. The entry barriers and opportunities for error for new and inexperienced developers must be as low as possible. An inconsistent namespace or even the possibility of circular dependencies make the use simply too complicated and difficult. At the end of the day, it’s all about the economic and productive development of applications.”
“Move some MicroProfile specifications (e.g. MP Config when its stable) to Jakarta EE including the namespace.”
Source Data
I really hope the results help pave the way for sensible decisions on Jakarta EE and MicroProfile alignment. For me, gathering input and listening to people that are not necessarily involved in the lower level details of specification development is extremely important.
The Eclipse Foundation very graciously ran the survey and shared the source data publicly. Reading all the comments in full is especially insightful.