Big +1. Jakarta Agentic AI is soon going to be in the same boat. Need a configuration mechanism but can’t depend on anything outside of Jakarta EE and would like to stick to using the jakarta namespace.
I never understood why it was necessary to revisit the entire API. Other than the namespace issue, MicroProfile Config is plenty good enough to be just evolved as needed under Jakarta EE once moved over. On May 14, 2026, at 9:42 AM, Ondro Mihályi via config-dev <config-dev@xxxxxxxxxxx> wrote:
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
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
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
--
|
