While there are specific discussions such as namespaces,
regarding the termination of the Config project, I agree with Ondro's opinion and +1 to keep it.
-Kenji Kazumura
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Ondro Mihályi via jakarta.ee-spec.committee
Sent: Monday, May 18, 2026 8:28 PM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc: Ondro Mihályi <mihalyi@xxxxxxxxxxx>; Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] [config-dev] Start Jakarta Config Termination Review?
Nothing in the JESP prevents specifications from using any namespace for API artifacts. The jakarta namespace is required only for former Java EE specs that used the javax namespace. MicroProfile Config can become a Jakarta
specification and keep the MicroProfile namespace.
The situation differs if MicroProfile Config aims to become part of the Jakarta EE Platform. Again, nothing in the Jakarta EE Platform specification prevents keeping the existing namespace, but the vast majority of Jakarta
EE Platform committers, the Jakarta Specification committee and the Jakarta EE community were against it in the past. So I doubt that MicroProfile Config would be adopted by the Jakarta EE Platform if it doesn't change the namespace to jakarta.
Because we really need a Config spec in Jakarta Platform, so that other platform specs can depend on it, we really need a Config spec with the jakarta namespace. If MicroProfile Config can adopt the jakarta namespace
and replace Jakarta Config, that would be awesome. If not, we need other alternatives.
Therefore I propose that we keep the Jakarta Config spec active and submit a progress review until it's clear whether MicroProfile Config can replace it. I also propose that Jakarta Config 1.0 is fully compatible with
MicroProfile Config, except for the namespace change and the dropping of any deprecated or problematic features. Additionally, it could include new, non-breaking features.
All the best,
Director, Jakarta EE expert
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.
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
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.
Gesendet: Donnerstag, 14. Mai 2026 um 20:14
Betreff: Re: [config-dev] Start Jakarta Config Termination Review?
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.
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.
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.
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.
Director, Jakarta EE expert
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.
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
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
