Re: [jakarta.ee-spec] Ballot on the MicroProfile specification namespace

[Emily Jiang <emijiang6@xxxxxxxxxxxxxx>]

+1 (IBM)

Thanks

Emily

On Mon, Nov 17, 2025 at 6:06 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

After another discussion at the Jakarta Spec Committee meeting last week, it was recommended to run the ballot at the Jakarta EE Spec Committee group.
If you want to refresh your memory about this ballot, you can find the discussion thread here.

Resolved: Retain the namespaces org.eclipse.microprofile.* for the existing MicroProfile specifications if and when MicroProfile joins Jakarta EE

This will be a seven-day ballot, ending on Monday, November 24, 2025, that requires a Super-majority positive vote of the Specification Committee members (note that there is no veto). Community input is welcome, but only votes cast by Specification Committee Representatives will be counted.

The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Tomitribe, Primeton, and Shandong Cvicse Middleware Co.), along with individuals who represent the EE4J PMC, Participant Members, and Committer Members.

Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.

Reasoning for the proposal:

The basis for this position rests on several pillars: technical, economic, and strategic.

1. 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. 

2. 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.

3. 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.

--

Thanks
Emily

--

Thanks
Emily