[
Date Prev][Date Next][
Thread Prev][Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cn4j-alliance] [DISCUSS] The future of Jakarta Config and MicroProfile Config
|
Hi all,
we are restarting the discussion about Jakarta Config and MicroProfile
Config in both Working Groups, Jakarta WG and MicroProfile WG, currently
and in yesterdays Jakarta Platform Call and MicroProfile Community Call
we decided to open it up here, in the CN4J Alliance mailing list as a
neutral ground of cooperation for topics like this.
A short history of the config spec: At the time of creation there where
discussions where to place it best, Java SE, Java EE or MicroProfile - I
personally joined an international JUGs meeting just before JavaLand
yeas ago. A the time, the future of Java SE and especially Java EE was
unsure for the community due to the transition from Sun to Oracle and
MicroProfile was created to move Java EE development forward. As it
becomes an Eclipse WG/project first, the config spec ended as
MicroProfile Config there.
Not a bad choice from my point of view, as it evolved there and now is
relative stable for a while. Many Jakarta (Platform) implementation
vendors added it to their products.
As Java EE was donated by Oracle to the Eclipse Foundation and becomes
Jakarta EE, discussions started how to collaborate between the Working
Groups and what might be their future role. About these organisational
aspects there is still no consensus...
However, successful collaboration took place in some technical aspects
like creation of the Jakarta Core Profile (containing common dependencies).
On the other hand, the transition of MicroProfile Config to Jakarta
Config stuck - because of some technical reasons like missing equivalent
to the MicroProfile Parent Project in Jakarta EE, the wish to support
the configuration of CDI itself (and Component Specs below the
dependency tree, but MP Config depends on CDI) and the scope of
functionality for the transition.
Dmitry presented a potential way out at an EclipseCon Community Day with
a Minimum Viable Product (MVP) approach to overcome some of this
restrictions.
But the first attempt was mostly blocked because of organisational
aspects - which a much harder to solve, especially for Software
Engineers...;-)
My idea is to restart the discussion, how the problem could be solved,
by adopting the pattern "form follows function" and start trying to
identify and solve the technical issues first and then come to the
organisational aspects. And there are good reasons to have that
discussion restarted:
One of reasons why the MicroProfile Config is so stable might be a
result of that unclear future of it - and if that's true, that needs to
be changed!
Jakarta Component Specs want to have the config spec support and vendors
overcome this in their implementations already - but that's not
specified in a vendor neutral way.
From my point of view most important (as I am representing a users
organisation): Users simply do not understand, why they need to do some
configuration in a XML file and other in a properties file etc. - this
complicates the configuration, especially in a Cloud Native environment.
And the answer that this is because of historic reasons does not satisfy
them at all.
The Jakarta EE wants to support Jakarta Config as part of the Core
Profile in version 12, where release planing has been started.
So there are multiple, sometimes combinable, options how to define the
MicroProfile Config and Jakarta Config future:
- 1-to-1 move of the spec from MicroProfile to Jakarta (Core Profile)
- Moving a subset of the spec to Jakarta Config only (like in the MVP
approach)
- Splitting MicroProfile/Jakarta Config into a Java SE based part and a
CDI based part
- Adding new config spec features
I omitted the simple addition of a dependency to MicroProfile Config by
Jakarta Component Specs, because this is a not a valid option at all:
MicroProfile Config depends on CDI and MicroProfile depends on Jakarta
Core Profile - adding a direct or transitive dependency from a Jakarta
Platform/Web Profile/Core Profile or Jakarta Component Spec links the
release cycles of both Working Groups directly with deviating
philosophies regarding long term stability and release cadences. In the
worst case a circular dependency could be created - which must be
prevented. An organisational solution could be the introduction of a new
organisation like a WG responsible for the Jakarta Core Profile
including MicroProfile Config, but this creates additional overhead and
does not solve the philosophy and cadence topic, so I didn't added it
too for now.
The 1-to-1 move of the Config spec would make sure, that 100% of the
features are available for MicroProfile future releases, but an eventual
package name change (to jakarta.*) and new properties file name
(jakarta-config.properties) will introduce breaking changes to
MicroProfile. A new MicroProfile Config release based on Jakarta Config
could compensate this by adding additional support to the existing
package name and properties file - where for the later the precedence,
if both files exist, need to be well defined too
(/META-INF/jakarta-config.properties and
/META-INF/microprofile-config.properties ConfigSource ordinal value).
Compatible Implementations could support both namespaces with a single
implementation.
A variant of this would be a move without changing names - then breaking
changes in MicroProfile are prevented, but users still might be confused
which namespace to use and this sounds to me like creating technical
debt because of organisational history (potentially forever)...
But technically, this option would have been a no-brainer for
MicroProfile and it's Component Specs.
The Jakarta Platform release management team (Arjan, Ed Burns, Jared)
proposed the 1-to-1 transition with the namespace change in the Jakarta
and giving a /META-INF/jakarta-config.properties default ordinal value
of 200 in the Jakarta Platform Call yesterday (2025-02-04).
Regarding the default ordinal value I personally have some concerns
(starting with 50 and then reordering all of them in 100 points steps
later sounds more logical to me, as MP depends on JEE) - but this needs
to be examined further regarding existing use of ordinal values above
100 and below 300 and potential breaking changes in applications and
vendor implementations.
Moving a subset of the features only as following the Jakarta Config MVP
approach would have some benefits to get consensus on the set of
features by finding a common ground, but requires tighter collaboration
between the WGs to cover the features without overlap. If missing
feature consensus on the Jakarta side is the blocker, this might be an
option to move forward - but currently it looks like this is not the
case (see above). Another use case of this is related to the next option
below.
Splitting the existing MicroProfile Config Component Spec into a core
part and a CDI dependent part would be nice to have Jakarta Config
(subset of MicroProfile Config) for Jakarta Component Specs below
including Jakarta CDI in the dependency graph and an additional Jakarta
Config CDI spec for the ones above (excluding CDI). MicroProfile was not
a driver of this split because it depends on the Jakarta Core Profile,
where CDI is included, but adds opportunities for adoption in Jakarta
Components Specs or implementations that do not depend on CDI like Spring.
Last but not least if there are new features regarding configuration
they could be added too - but especially here and to the split option
above we need to make decisions about where and when it will be done to
prevent breaking changes.
At the moment, I personally prefer the 1-to-1 move to Jakarta of
MicroProfile Config, but doing the split within MicroProfile first to
make benefit of the faster release cadence there (by creating a
MicroProfile Config Core spec out of MP Config - which prevents breaking
changes). Then creating a Jakarta Config (Java SE based) out of it, a
Jakarta Config CDI for the remaining parts and if necessary a new
MicroProfile Config based on it, but granting compatibility to the
Microprofile namespaces (this could be dropped in a MicroProfile Major
Release only). New features should be done in MP first until they a
stable and potentially moved to Jakarta Config/Condig CDI then in the
future (Jakarta Platform 13+). But the split could be done within
Jakarta EE too, when being fast enough there or doing the split there
later. A little challenge is to establish an equivalent of the MP Parent
project in Jakarta - but this could be a general topic for Jakarta EE 12
component specs too - a shortcut would be taking the defaults to Jakarta
Config/Jakarta Config CDI POMs, but this would be a step back into
technical debt again - having an equivalent Jakarta Parent instead would
be preferred by me.
This approach takes organisational aspects into account as philosophical
ones like following "move fast and break things" and higher release
cadence in MicroProfile, so these benefits could be used to give Jakarta
stability - vendors and users would make benefit of both with their
strengths.
So this is my view on this topic - now its up to you to join the
discussion and share your thoughts!
When the discussion stabilised somehow, we would announce a meeting to
discuss the topics face-to-face in detail, maybe having separate
meetings for the technical and organisational aspects, if required.
Please announce this discussion in relevant mailing lists, but keep the
main thread here for the general topics - so people from both WGs can
follow easily.
Best,
Jan
