| [config-dev] Jakarta Config current status and possible direction |
Hi Ondro,
Thank you again for the detailed context and for pointing me to the previous discussions.
I have been going through the MicroProfile Config specification, the Jakarta Config discussions, and some of the historical issues around configuration semantics. This has helped me form a clearer opinion about what Jakarta Config 1.0 could reasonably aim for.
My current view is that Jakarta Config 1.0 should use MicroProfile Config as the proven baseline and should avoid redesigning configuration from scratch.
Historically, MicroProfile was created to allow Enterprise Java to move faster and experiment in areas where the formal standardization process could not evolve quickly enough. MicroProfile Config has now accumulated several years of implementation and production experience, so I think Jakarta Config should benefit from that experience rather than repeat the experimentation phase.
Regarding the points you raised, my current position would be:
Jakarta Config should aim to become the standardized successor of MicroProfile Config.
If that is the goal, I think the namespace should be jakarta.*.
Migration from MicroProfile Config should be intentionally inexpensive. Ideally, for most application code, changing imports from org.eclipse.microprofile.config.* to jakarta.config.* should represent most of the migration effort.
The core API should remain usable independently of CDI. CDI integration is very valuable for Jakarta EE applications, but I believe CDI should consume/integrate with Jakarta Config rather than be a prerequisite for configuration itself.
I would avoid adding major new features to Jakarta Config 1.0 unless they are necessary to avoid an architectural dead end.
I have not found many MicroProfile Config features that I would consider obsolete. My default position would be to preserve existing behavior unless there is a concrete reason to change it.
While reviewing the specification, I found a few areas that I think are worth discussing carefully.
One is the distinction between a missing property and an explicitly empty property.
For example, I see these as different states:
property not present
and:
property=
I understand the historical reason why MicroProfile Config uses the empty string as a way for a higher-priority ConfigSource to clear a value from a lower-priority source. I also reviewed the discussion around issues #446, #531 and #532, and I think the clearing use case itself is completely valid.
However, using the empty string to represent "cleared/non-present" also means losing the distinction between an explicitly configured empty value and an absent value.
Conceptually, I think these are different states:
ABSENT
PRESENT_EMPTY
PRESENT_VALUE
CLEARED
I am not suggesting that Jakarta Config 1.0 must necessarily expose those four states directly in the API, but I think it is worth reviewing whether the model should preserve that distinction rather than conflate empty and absent.
This also seems relevant for future structured configuration support, where formats such as JSON naturally distinguish between a missing member, null, an empty string, and a non-empty value.
Another area is dynamic configuration.
I think Jakarta Config should support dynamic ConfigSources in 1.0. The specification should define portable observable behavior while leaving caching, polling, watches, and similar mechanisms as implementation details.
In other words, I think the specification should define configuration semantics rather than mandate a particular caching strategy.
A runtime may cache aggressively, but that should not effectively turn a source declared as dynamic into a static source.
Regarding Kubernetes ConfigMaps and Secrets, I currently see them primarily as possible ConfigSource implementations rather than something Jakarta Config itself should depend on.
The same configuration may reach the application through environment variables, mounted files, or a dedicated ConfigSource. Those are different transport mechanisms, even if the original source was Kubernetes.
I also think there is value in preserving information about sensitive values.
From a lookup perspective, a secret is still configuration. However, a ConfigSource that knows that a particular value came from a Kubernetes Secret, Vault, Azure Key Vault, etc. could potentially preserve metadata indicating that the value is sensitive.
I do not think Jakarta Config can guarantee that a secret will never be logged once an application explicitly converts it to a regular String. But preserving sensitivity metadata could help avoid accidental exposure by Jakarta Config itself and by tooling built on top of it.
It may also be worth exploring in the future whether sensitive values should support a representation that requires an explicit operation to expose their clear value, similar in spirit to why Console.readPassword() uses char[] rather than String.
For 1.0, however, I would be careful not to let this grow into a large new security API.
On structured/tree configuration, I do see value in it, especially for JSON/YAML-style configuration and object mapping. But I would explicitly keep full tree navigation, merge semantics, arrays, and hierarchical overrides out of the 1.0 scope. I think they should be considered in the design so that 1.0 does not make them impossible later, but they should not delay the first release.
Regarding existing MicroProfile Config features such as profiles, property expressions, converters, source ordinals, and deterministic ConfigSource ordering, I currently see strong reasons to preserve them.
In particular:
Profiles are very useful in practice.
Property expressions are fundamental when values come from multiple configuration sources.
Converters provide a clean way to adapt String-based configuration to application types.
ConfigSource ordinals and the current deterministic tie-breaking behavior should remain unchanged for compatibility.
Lookup should be fundamental, while full enumeration of all properties may deserve to be treated as an optional capability for remote or security-sensitive sources.
Overall, my current preference would be:
Start from MicroProfile Config.
Keep the 1.0 scope deliberately small.
Preserve existing, proven behavior by default.
Change behavior only where there is a clear semantic or architectural reason.
Keep the architecture extensible for future structured configuration and richer secret handling.
I am still learning the specification process and I may be missing historical context in some of these areas, so I would be very interested to know which of these points align with the current Jakarta Config API and which ones have already been discussed or rejected in the past.
Best regards,
Diego
Hi Diego,Nice to see that you want to join us and contribute to the Jakarta Config specification.Currently, the specification project has been dormant for several years. We'll need to submit a progress review to keep it formally active and enable us to release a new version when we are ready. We plan to submit the progress review some time after summer holidays.The project is in a state where it attempted to recreate and improve the MicroProfile Config specification but then stalled due to endless discussions about adding or refining features. The current API is in a pretty good shape but it needs a review to see whether all is reasonable and can be released as version 1.0 of the specification.I recommend reading the latest discussion about the current status and future of the specification on this mailing list: https://www.eclipse.org/lists/config-dev/msg00257.htmlThe specification has many committers, but only a few have expressed a desire to continue working on it. The hard question now is whether we can continue and finish what is already in the repository, or rather just take the latest Microprofile Config specification and possibly change the package name to jakarta.* and release it as Jakarta Config 1.0.There are a few points which often lead into lengthy discussions and disputes and I believe are still open, without any formal or even informal conclusion:
- Should we have the goal that Jakarta Config 1.0 is a successor to the MicroProfile Config spec and MicroProfile adopts it instead of MicroProfile Config?
- If we base the spec on MicroProfile Config, should we keep org.eclipse.microprofile namespace or switch to jakarta.* namespace? I guess this makes sense only if we have the goal above (replace MicroProfile Config)
- Should we focus on API for application developers, hence CDI-first approach, or primarily support Java SE API so that other Jakarta EE implementations can use it for configuration, even without a CDI dependency?
- Should we support some additional features not yet covered in MicroProfile Config in Jakarta Config 1.0, or avoid it and postpone adding new features to later versions?
- Should we drop some MicroProfile features that are obsolete or undesirable?
From your point of view, I also recommend exploring how the current Jakarta Config repository or MicroProfile Config aligns with your experience using Kubernetes ConfigMaps. Does the mapping from plain string properties match well enough or is a tree structure more suitable? Is it useful to distinguish between configuration properties and secrets or is it OK to treat secrets as regular configuration?All the best,Ondro MihalyiDirector, Jakarta EE expertOn Tue, Aug 11, 2026 at 5:46 PM Diego Silva via config-dev <config-dev@xxxxxxxxxxx> wrote:_______________________________________________Hi everyone,
My name is Diego Silva, and I recently joined the Jakarta Config mailing list after speaking with Otavio Santana about getting involved with Jakarta EE specification projects.
I am a Java developer with experience working with Jakarta EE and related technologies, and I am currently particularly interested in configuration management. In my current work, I deal with Kubernetes ConfigMaps and applications running on AKS, which is one of the reasons Jakarta Config caught my attention.
I am here mainly to learn how the specification project works, follow the discussions, and contribute wherever I can. I have started reviewing the Jakarta Config documentation and GitHub repository, and I would be happy to help with documentation, examples, issues, testing, or other areas where the project needs support.
If there are any good first issues or areas that would be useful for a newcomer to explore, I would really appreciate any suggestions.
Looking forward to learning from all of you and contributing to Jakarta Config.
Best regards,
Diego Silva
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org