Hi Werner,
The Jakarta EE platform specification also states:
>As defined in the Jakarta EE Specification Process 1.4, APIs artifacts (API jars, javadoc, schemas) produced by a specification project are the >only artifacts that must make use of the jakarta.* package namespace.
I am afraid your understanding was not correct. The JESP said:
Use of the jakarta namespace is limited to API artifacts (all API jars, javadoc, and schema namespaces).
It must not be used for any deployment, including applications, TCKs, tools, libraries or any other assets produced by Specification Projects.
It means that the jakarta namespace can only be used by APIs not by TCKs or others. It does not say all APIs must use jakarta namespace. There was an attempt to change this process to add such a restriction via
this voting. However, the attempt did not succeed.
Thanks
Emily
================
Emily Jiang
Java Champion, Fellow of BCS
STSM, Jakarta and MicroProfile Architect @IBM
Liberty Cloud Native Architect & Advocate
Hi, The Jakarta EE platform specification also states: >As defined in the Jakarta EE Specification Process 1. 4, APIs artifacts (API jars, javadoc, schemas) produced by a specification project are the >only artifacts that must make use
Hi,
The Jakarta EE platform specification also states:
>As defined in the Jakarta EE Specification Process 1.4, APIs artifacts (API jars, javadoc, schemas) produced by a specification project are the >only artifacts that must make use of the jakarta.* package namespace.
The idea of a fully compatible drop-in-replacement based on MP Config, as Mark hinted he and Emily could lead, sounds appealing.
It would be in the spirit of the original namespace change between Jakarta EE 8 and 9 and make adoption and acceptance a lot easier.
Even if CDI on an API/spec level may not directly reference a config spec, having MP Config being dependent on CDI would create an
awkward circular dependency between org.eclipse.microprofile.config and the jakarta.* namespace, which is a key reason, why for a platform spec, that should be avoided, while a standalone spec may have no problem with it.
Fault Tolerance and most other MP specs look more relevant on an implementation level, for compatible Jakarta EE products, while config likely could be used by other specs and APIs in
future versions.
Best Regards,
Werner
Gesendet: Donnerstag, 14. Mai 2026 um 20:14
Betreff: Re: [config-dev] Start Jakarta Config Termination Review?
Hi Emily,
That's the attitude of the Jakarta Platform. Most of the people I talked with have no problem accepting the MP prefix in standalone Jakarta specifications but to be accepted into the Platform, a specification must have the jakarta prefix. It isn't dictated
by any rule but it's something that the vast majority of Jakarta Spec Committee reps want and also almost everybody in the jakarta EE community wants.
The jakarta prefix wouldn't be essential for example for MicroProfile Fault Tolerance spec, if MP moves to EE working group, as long as the Fault Tolerance stays a standalone Jakarta spec or part of Jakarta MicroProfile group of specs. But we're talking
here about Config, which is really essential and Jakarta EE should have had it years ago.
All the best,
Ondro Mihalyi
Director, Jakarta EE expert
David, I understand your points and largely agree, under a single condition. There must be a way to provide an alternative config API in Jakarta EE. MicroProfile is adequate alternative, but the problem is that it's not in the Jakarta EE Platform and other
specifications cannot depend on it.
There is high demand for a common configuration mechanism in Jakarta EE. This cannot be compared to logging, which is a nice to have feature but there's little demand for standardizing it. The missing config API in Jakarta EE is becoming a significant
blocker. For example, the Jakarta NoSQL team expressed a need for a configuration mechanism. Its reference impl, JNoSQL, already depends on MicroProfile Config, but this cannot be standardized in the spec. We recently discussed the need for a common configuration
for Jakarta Persistence in
this issue. I know more specifications would use the common config if it existed.
I would like that MicroProfile Config is added to Jakarta EE as is, but for that, 2 things must happen:
- MP Config must be transferred to the Jakarta EE WG, either as a single spec, or together with merging the MP and EE Working Groups
- MP Config must adopt the jakarta prefix
Why? I disagree with these things being mandatory. The JESP does not require that all apis must adopt the Jakarta prefix. This was an old conversation we had last year, by the way.
When we broadly discussed this, there were few objections to moving MP Config to Jakarta EE. It's a stable API, doesn't evolve very frequently, so even those who are afraid that Jakarta EE would have a slower release cadence than MicroProfile wouldn't
mind.
About the jakarta prefix, I'm unsure if there is enough support for it. i think that specifically for Config it shouldn't be a problem. Different package prefixes allow supporting both APIs in existing servers if backward compatibility is needed.
I'd like to get some more real support for moving MP Config to Jakarta EE, including adoption of the jakarta prefix, before we decide to terminate the Jakarta Config spec. Otherwise I would rather support having both MP Config and Jakarta Config, even
if Jakarta Config is basically just a copy of MP Config under the jakarta prefix.
It's already a shame that Jakarta EE 12 still won't have any standardized config mechanism and I hope we can all do something about it.
All the best,
Ondro Mihalyi
Director, Jakarta EE expert
I'm skeptical to say the least. Much like the often-suggested yet never-materializing "Jakarta Logging", the discussion typically centers around what implementation it should be based on, or what existing
API to derive it from. But this is not the right approach for specifying something like this.
The way I see it, you need to follow one of two approaches if you want to define a successful specification:
1. Take a widely-used, de-facto standard and make a formal standard out of it (this would be MP config)
2. Start from the beginning by identifying use cases and user categories/roles, and derive requirements from there, and then drive a clean-room design from that work (we tried this and nobody could agree
on the use cases or user categories/roles)
I think option 1 is pointless. MP config already exists, flaws and all, and having two specs saying the same thing seems like a waste of energy to me. And option 2 I think won't fly unless you can remove
some people/orgs from the WG or dramatically change their views.
IMO this effort should be terminated.
Hi,
Jakarta Config is very important for further Jakarta EE development and it's long overdue. It's a pity that the project has been dormant for so long, despite having so many committers.
In fact, I plan to initiate a restart of the work on the spec later this year. I already talked to a few committers. A problem is that many people expect that MicroProfile WG will join the Jakarta EE WG and then Jakarta Config will be based on MicroProfile
Config or possibly MicroProfile Config will be superceeded by Jakarta Config.
In the current situation, I'm not sure whether it's better trigger a progress review for Config spec to keep it live or to terminate the current spec and restart a new spec once we are ready to work on it, possibly after MicroProfile WG joins the Jakarta
WG. I would be for initiating a progress review to keep it live for a while.
All the best,
Ondro Mihalyi
Director, Jakarta EE expert
Hi,
This project is approaching two years overdue for a progress review on its inaugural 1.0 release.
Is there any interest in keeping this project alive, or should we move to start a
Termination Review?
The specification committee previously agreed to holding a two-week lazy consensus period before kicking off the termination review. This two week period will end on the
27th of May.
Thanks,
Andrew Pielage
--
- DML • he/him
--
Thanks
Emily
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
