| Re: [jakarta.ee-spec] Ballot on the MicroProfile specification namespaces if and when they move to Jakarta EE |
|
--
|
|
Andrew Pielage
Senior Software Engineer |
The basis for this position rests on several pillars: technical, economic, 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 the 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.