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

[David Lloyd <david.lloyd@xxxxxxxxxx>]

On Fri, Apr 3, 2020 at 12:27 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
> Hi,
>
> On Fri, Apr 3, 2020 at 7:10 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>
>> The very fact that you point out how all vendors have non
>> interchangeable features indicates that it's not quite ready yet!
>
>
> I hear you, but by that token, would JPA be ready for inclusion in Jakarta EE today if by some twist in history it was never included and was now in MP instead?
>
> All JPA vendors have proprietary features even today.

This is a good data point, and a hard question that should be asked
is, "can we do better?".  Maybe that was the best that could be done
at the time, maybe not.  A standards body should strive for quality,
and that is not something that just *ends* one day.

>> There's only one road to stabilization, and freezing some
>> random thing *now* is not that road.
>
> I hear you again, but who's talking about *freezing* things?
>
> If a spec moves to Jakarta, it's not frozen. Though we still haven't decided on the exact cadence for Jakarta EE, the proposals uttered ranged from between three months and a year.

To clarify this point a little: moving the spec to Jakarta isn't
possible without buy-in from the people developing the spec, since
without that buy-in, we would simply continue to develop it in MP
Config, making it a "fork" not a "move".

> If you take into account specs can release things in-between Jakarta releases even, then in my book that doesn't quite sound as freezing the spec, does it? Or did you mean something else there?

Several things are possible, but there are a few basic assumptions.
The first assumption is that no matter what, it is very, very unlikely
that anyone will successfully force or convince the MP Config spec
team to stop working on the spec, at least for now.  So given that, if
Jakarta decides to fork the spec, they can either take a snapshot in
time, effectively freezing at the point where it was forked, or it can
continue to develop the spec.  Given that MP Config are also
developing the spec with (ostensibly) the same motivations (that is,
identifying and meeting the majority of significant use cases in a
specification with good quality), then either work will be duplicated
or Jakarta will be trailing behind MP (since MP can always pull things
from Jakarta, but Jakarta (due to compatibility restrictions) may not
be able to pull things from MP).  So given that, it is illogical
(though obviously possible) to fork and *not* freeze (at least from a
compatibility perspective).

This is why it makes far more sense to let MP Config work for a while:
the starting line for Jakarta Config would be in a far better position
as a result.
-- 
- DML