Re: [jakarta.ee-community] Options for Jakarta EE and MP alignment

[David Lloyd <david.lloyd@xxxxxxxxxx>]

On Fri, Apr 3, 2020 at 11:48 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> Well the MP Config that's there right now is not even compatible with Jakarta EE 9 hence as a basis for a Jakarta EE 10 inclusion (or using it side-by-side on top of Jakarta EE 9) that release is not even there.
>
> If you look at how much other truly Cloud-aware solutions like Helidon or Tamaya add on top of MP-Config or beside it, you see that it covers only a small fraction. The rest is up to the vendors, and while I have not dug so deep into their implementations, I am pretty sure Wildfly or Liberty as well as Payara add some value around it that you find in Helidon or Tamaya (or e.g. Archaius once got by Netflix) that are vendor-specific and not interchangeable.

I can't speak for other vendors, but from our point of view, a primary
reason that we include functionality outside of the spec is with a
view towards trying out ideas, preliminarily to proposing them in the
spec itself.  Implementation first, spec follows, stabilization comes
after that.

> These are not compatible even if the core of config was frozen for some time and a proper outbound TCK was found that works also as part of a Jakarta EE platform test.

On the contrary, freezing the spec is what causes the permanent
incompatibility in this case.  Give vendors a chance to converge on
best practices!  It's easy for one vendor to put out an implementation
of an idea; it takes a little longer for many vendors to come together
and standardize around common ideas and use cases. Isn't that what we
want for standards bodies like Jakarta?  Trying to ram something
through just to have something will earn you a reputation for
producing garbage IMO.

The very fact that you point out how all vendors have non
interchangeable features indicates that it's not quite ready yet!
Once the spec addresses all of the major use cases currently
implemented by long-standing vendor features, then you can be
confident that not only is the specification ready for stabilization,
but also that vendors are far more likely to want to (and be able to)
adopt it.  There's only one road to stabilization, and freezing some
random thing *now* is not that road.
-- 
- DML