MP Concurrency vs EE Concurrency

[Arjan Tijms]

Hi,

I'm a bit late to the party and didn't fully read the "Bring Concurrency to MicroProfile" thread and didn't fully read all the code that has been contributed so far, but one thing I wonder about is positioning MP Concurrency vs EE Concurrency.

Many vendors that implement EE also implement MP, so in practice it seems to mean we would have to maintain two very much overlapping efforts, and our users have to choose between two very much overlapping APIs to choose from.

Quite a number of things that are being worked on for MP Concurrency are also in scope for EE Concurrency, e.g. things like the context propagation and using CDI to inject the various concurrency resources.

Thoughts?

Kind regards,

Arjan

[Nathan Rauh]

It isn't meant to be one vs the other.  MP Concurrency has been designed to be fully compatible with EE Concurrency, such that a single implementation can easily be both.  We are hoping that much of the MP Concurrency spec will eventually be adopted into EE Concurrency.

[Kevin Sutter]

I agree with Nathan.  There were some necessary updates to the EE Concurrency spec to allow for a more efficient threading model with some of the MP components (ie. Fault Tolerance).  But, since Jakarta EE isn't far enough along to allow for changes beyond Java EE 8 yet, the effort was started here in MicroProfile.  As Nathan points out, one of the goals of this effort is to extend the capabilities defined by EE Concurrency, not compete with it.  And, once the processes are all figured out for Jakarta EE, then hopefully this effort can be consumed by EE Concurrency.

-- Kevin