Shandong Cvicse Middleware Co.
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.
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.
--
Thanks
Emily
