Great points.Has anyone thought about working with the JDK team on an “alias” feature for package names in the default ClassLoader? It seems like package names is a proliferating issue, and maybe it can be solved at the language level. On Oct 14, 2025, at 5:53 AM, Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:
Hi all, I'd like to take a moment to emphasize that namespace uniformity defines the platform’s integrity. It’s part of the shared mental model that makes Jakarta EE a platform rather than a collection of unrelated jars.
The current proposal focuses narrowly on short-term migration pain, while I believe we should look at the long-term architectural and cultural cost of fragmentation.
A platform with mixed namespaces is not a coherent API surface. It perpetuates legacy boundaries indefinitely and signals to both developers and vendors that “Jakarta EE is not one thing.” That undermines confidence in the platform’s long-term stewardship.
Let’s not forget that the “we can’t break existing users” argument has been made at every namespace transition since JDK 1.1, from javasoft.* -> javax.* -> jakarta.*.
Time and again, history has shown that each painful break was eventually the right call: it enabled clarity, consolidation, and modernization. To that effect, the goal should be to honor MicroProfile’s contribution by making it a first-class citizen in Jakarta EE, not by isolating it behind a legacy namespace. We want its innovations to live within Jakarta EE’s architecture, not beside it.
We’ve just spent years unifying everything under jakarta.* for consistency and clarity. Re-introducing another external namespace now would re-create the very fragmentation we worked so hard to fix.
Of course, we can and should protect users through transitional compatibility artifacts, but the direction must be clear: the unified platform is Jakarta EE, not a federation of legacy namespaces.
Imagine if the Jakarta platform in 2030 consisted of jakarta.enterprise, org.eclipse.microprofile, com.sun.enterprise, com.oracle, and say org.omnifaces. The platform would no longer feel cohesive. A unified namespace is part of what makes a platform a platform.
Let’s design a path that welcomes MicroProfile’s APIs into the jakarta.* namespace while giving developers time to adapt; just as Jakarta EE itself did successfully.
That’s how we build one unified platform that honors both histories.
My 2 cents,
Arjan Tijms I was thinking this was the case as well, but was not sure. Thanks for confirming Joakim.
Ondro,
What you are referring to is the `<relocation>` element in the Maven Pom.
It would exist in old maven coordinates, pointing to the new maven coordinates. Thing is, this relocation is version specific, it doesn't apply to all versions (now and in the future).
- Joakim Hello, Emily,
Thank for this proposal, and for including detailed reasoninh in it. For the case of maven artifacts, did you consider aliasing of artifacts which is supported by Maven Central? Even if an artifact is renamed, with this approach, it’s possible to use old artifact coordinates with new versions, and Maven automatically pulls artifacts that have the new coordinates.
Ondro
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
