This has been a very long thread with many different points
Taking the package namespace
>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.
It is not just an extra package, that would start with "org.eclipse" instead of "jakarta". The JDK contains various "org.w3c" and other 3rd party packages, even the Spring Framework has a few "org.aopalliance" ones, and Micrometer, while maintained by the same community and companies has its own package namespace, too.
It is also about responsibility, if a major CVE came up, similar to say Log4Shell. MP Config itself may have been archived by some Eclipse standards, given there has been no major release in 3 years, and some open issue ticket are as old as 9 years.
The only active corporate committers to MicroProfile are IBM and Red Hat according to the (overall) project page.
As long as they guarantee even for a High Level CVE or similar vulnerabilities, to address those, the names of packages used may be the lesser problem.
Beside Microprofile Config, there ae not too many well-maintained alternatives, other than Spring and maybe Apache Commons Config.
Similar to logging btw, with Log4J, SLF4J and the Java Platform Logging all offer a logging facade that is somewhat standardized (especially for the JDK) so the ill-fated Logging JSR or Jakarta Logging attempts are met by specs that are either standards or defacto standards for some time and there is no sign of say the JDK getting rid of that like e.g. the SecurityManager.
Regards,
Werner
Gesendet: Donnerstag, 14. Mai 2026 um 19:03
Betreff: Re: [config-dev] Start Jakarta Config Termination Review?
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
_______________________________________________
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
--
_______________________________________________
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
