As promised, here is the proposal I put together with some input from my IBM colleagues. I plan to start a ballot in the Jakarta EE platform dev mailinglist next week.
Context
The merger of MicroProfile specifications into Jakarta EE represents a joint community for the Java enterprise ecosystem. However, for this merger to be successful, it is imperative that the org.eclipse.microprofile namespace and artifact names (e.g., microprofile-config) be preserved for all APIs and specifications originating from the MicroProfile community.
This is a strategic necessity to protect the vast existing global investment, ensure backward compatibility, and prevent ecosystem fragmentation. Changing the namespace to jakarta would cause the existing implementers and their customers pain and confusion while negating the very benefits this merger seeks to achieve.
The proposal
Resolved: Retain the namespaces org.eclipse.microprofile.* for the existing MicroProfile specifications when MicroProfile joins Jakarta EE
The basis for this position rests on several pillars: technical, economic, governance, and strategic.
Technical Basis: The Unbreakable Contract of Backward Compatibility
· The Maven Coordinate as a Universal Identifier: In modern Java development, a Maven groupId:artifactId (e.g., org.eclipse.microprofile:microprofile-config-api) is a unique, immutable contract. Build tools (Maven, Gradle), CI/CD pipelines, registries (Maven Central, Nexus), and IDEs all rely on this coordinate never changing for a given version of a library.
· Impact: Changing the namespace to jakarta (e.g., jakarta.microprofile.config:config-api) creates a new, incompatible artifact. Every existing application, every line of code import org.eclipse.microprofile.config.*;, and every pom.xml or build.gradle file would require mandatory, invasive changes to migrate. This is not an upgrade; it is a forced, costly, and error-prone rewrite for many production microservices.
· The Jakarta EE Precedent: Jakarta EE itself faced this exact challenge when moving from javax.* to jakarta.*. See the example below for the pain and complexity of this namespace change. It would be regrettable to inflict this same pain on the MicroProfile community.
Example: with the javax-to-jakarta package name switch where customers write application code using only the class name, like @Resource and save, after which the IDE auto-computes the import statements. The developer spends time and effort trying to figure out why their annotation isn't honored, even going so far as to open support cases, which our support teams spend time and effort trying to debug, before someone eventually figures out that wrong package name is used. We expect more of the same if microprofile classes are duplicated into jakarta packages, whereas this added cost of development and source of frustration to our users is completely avoided if the package names are left alone.
Economic Basis: Protecting Global Investment
· The Cost of Change for customers: The man-hours required for every development team to replace, test, and redeploy all their services could represent a considerable amount of cost and time. Preserving the namespace protects this global investment, allowing for a seamless transition where new Jakarta EE versions can simply include and enhance the stable MicroProfile artifacts.
· The Cost of Change for implementers: Resources are finite. Time spent by implementers to adapt to the namespace change and helping their users do so means resources not spent on driving the Jakarta / MicroProfile ecosystem forward.
Strategic Basis: Unification, Not Absorption
· The Goal is a Bigger Tent: Joining MicroProfile with Jakarta EE provides a more complete programming model for both monolith and microservices architecture.
· The Ecosystem Fragmentation: If the namespace is changed, it will inevitably fragment the community. Some vendors and projects would adopt the new jakarta.microprofile.* artifacts, while others, prioritizing their users' stability, might continue to ship and innovate on the org.eclipse.microprofile.* artifacts. We would end up with two competing sets of identical APIs, undermining the unity this effort is meant to create.
Conclusion and the Path Forward
Considering the advantages and disadvantages of preserving vs. altering the namespace, the most beneficial path is to preserve the microprofile namespace under Jakarta EE. The correct path is to:
Formalize the Merge in the Jakarta EE Platform.
Preserve the `org.eclipse.microprofile` Namespace: Keep the existing package names and Maven coordinates.
Let Runtimes Do the Work: Jakarta EE runtimes will simply bundle the existing MicroProfile JARs, providing a unified platform out-of-the-box.
This approach achieves the ultimate goal—a unified, full-featured platform for enterprise Java—without breaking existing code, and respecting the unique identity and innovation pipeline of the MicroProfile community. The namespace must be preserved.
