Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Proposal: Retain the namespaces org.eclipse.microprofile.* for the existing MicroProfile specifications when MicroProfile joins Jakarta EE
I don't agree with the namespace changes in the future version of EE releases. If a MicroProfile spec is merged into an existing Jakarta EE spec, this MicroProfile spec will be deprecated and there is no need to change the namespace. In this scenario, it is okay to rework on the APIs with new namespaces. 

MicroProfile Context Propagation is an example of that. Most of the APIs from MicroProfile Context Propagation have been merged into Jakarta Concurrency and the MicroProfile Context Propagation has been deprecated and is at a maintenance level.

image.png

Thanks,
Emily

On Mon, Oct 13, 2025 at 4:26 PM hantsy bai via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
I think the namespace changes can be accepted in future Jakarta EE versions, such as 12 or 13. To leave more room for developers to migrate, the current version and maintenance versions will be retained for use with the old org.microprofile namespace. 
As an end user of Jakarta EE, I care more about the future of handling some existing work in Microprofile, for example, 
1. MP RestClient will be merged into Jakarta Rest?
2. MP JWT will be merged into Jakarta Security soon?
3. Context Propagation will be merged into Jakarta Concurrency or CDI Context?
4. Reactive messaging and JMS relation?
5. Fully embrace Reactive Streams in Jakarta Concurrency/CDI Context? Because MP Rest Client and Reactive Messaging are reactive-friendly.
---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy


On Mon, Oct 13, 2025 at 9:51 PM Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
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.

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

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


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

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--
Thanks
Emily

Back to the top