Joining MP and EE?

[Arjan Tijms]

Hi,

MP and EE are both Eclipse Foundation projects, following pretty much the same specification processes, are contributed to by pretty much the same people and are implemented by pretty much the same products.

Instead of presenting outselves as one framework that covers a lot of usecases with our powerful APIs, we artificially make ourselves look smaller than we actually are.

MP was once started when the EE APIs were still at Oracle, and the EE future was not clear. Many (pretty much all) of the MP features were already planned and some (like Config) extensively discussed and worked on for what was at the time Java EE 8 and Java EE 9. 

Those APIs were subsequently added to MP,  out of necessity, but were always intended for EE.

Ever since EE also moved to the Eclipse Foundation, it basically wasn't necessary to keep MP and EE officially separate. Next to the PR issues (making us look smaller than we actually are), we also have a ton of practical issues. For instance, Data, REST, CDI etc cannot use Config, while MP can't depend on say Validation.

I would therefor like to propose to merge EE and MP.

Thoughts?

Kind regards,

Arjan Tijms

[Buhake Sindi]

Hi,

I completely agree with your proposal to merge MP and EE. It makes sense for us to present ourselves as a unified framework, especially considering the overlap in contributions and specifications.

In fact, it's long overdue.  It's a +1 from me.

Thanks,

Kind Regards,

Buhake Sindi

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/fd02d06f-ec9f-4259-b506-1230ca34f76cn%40googlegroups.com.

[David Matějček]

+1 from an Eclipse GlassFish lead. 

[Roberto Cortez]

Hi Arjan,

Less than a year ago, there was a proposal to move MP to Jakarta, which unfortunately didn’t go through. 

What changed in the meantime that would allow us to reach a consensus? I haven’t seen any further debate on the matter, but maybe I’m not following the proper channels and missed it.

Thank you!

Cheers,

Roberto

[Arjan Tijms]

Hi,

On Thursday, 10 September 2026 at 23:21:08 UTC+2 radc...@yahoo.com wrote:

Hi Arjan,

Less than a year ago, there was a proposal to move MP to Jakarta, which unfortunately didn’t go through. 

Maybe the simple answer is to Just Do It this time?

What changed in the meantime that would allow us to reach a consensus? I haven’t seen any further debate on the matter, but maybe I’m not following the proper channels and missed it.

Maybe I'm missing something, but I feel like everyone wants this. There truly is no reason not to do it. It's something we should have done right away when EE moved to the Eclipse Foundation. We just need to actually do it, and that's where it halted before I think. We just need to go ahead with it, instead of waiting and then "forgetting" again we were going to do it?

Again, I might be missing something, but that's how it feels to me. 

Kind regards,

Arjan Tijms

[Roberto Cortez]

Hi Arjan,

I agree that we should have a unified group at this point.

I believe the big blocker is the namespace. I’ve read the past conversations, and most members are only willing to move forward with an all-or-nothing approach: merge, yes, but with a full namespace rename (microfile to jakarta).  We can argue that it was done before with javax to jakarta, but I believe there are three fundamental differences:

- javax was effectively legally blocked, meaning that renaming was the only way to move forward.

- While Microprofile is considerably smaller than Jakarta, there are also fewer resources working on the project today than when we first started, so who is going to do the work? Remember that this also affects implementations and consumers. We had a justification before (see previous bullet), but now I don’t see a good justification for something that will bring zero short-term value to users, and long-term value is still to be determined.

- The javax to jakarta was essentially only a rename. Here we have a merge with a possible rename, which opens up a lot of unanswered questions (at least in my mind; maybe for others these are clear):

- Should we keep MP Config or go with a new Jakarta Config?

- Should we keep JWT, or should it be merged with Jakarta Security / Authentication / Authorization?

- Should we keep REST Client and OpenAI, or should they be merged with Jakarta REST

- Should we keep Reactive Messaging, or should it be merged with Jakarta Messaging?

- What about Fault Tolerance and Health? Keep them standalone? Or should they live in another Jakarta spec?

- What about deprecated OpenTracing and Metrics? Is there any point in those?

- And many other questions...

Pragmatically, MP should be merged into Jakarta as is, and then we can have these conversations and decide what to do with each spec. To be clear, I don't disagree with a rename, but I disagree with doing it blindly for everything. Do we really want to rename JWT only to decide later that it should be part of something else, and have to do another rename? (and that is mostly a given already with the JWT Bridge)

Most of the discussion is about a consistent namespace in the platform. I get it, but consistency is not only about namespaces. APIs matter way more to me than mere namespaces, which these days are mostly hidden from consumers. I get way more frustrated when I forget to include REST Client than by the namespace it uses, because it should be part of Jakarta REST. 

This could be an opportunity to make things consistent and coherent if we accept that we don’t have to rush and rename everything, and only do it when we're also delivering value to our users.

Cheers,

Roberto

To view this discussion visit https://groups.google.com/d/msgid/microprofile/a2744db7-c32b-4ed1-9b25-ff7d358a046fn%40googlegroups.com.

[Arjan Tijms]

On Fri, 11 Sept 2026 at 16:48, 'Roberto Cortez' via MicroProfile <microp...@googlegroups.com> wrote:

Hi Arjan,

I agree that we should have a unified group at this point.

I believe the big blocker is the namespace. I’ve read the past conversations, and most members are only willing to move forward with an all-or-nothing approach: merge, yes, but with a full namespace rename (microfile to jakarta).  We can argue that it was done before with javax to jakarta, but I believe there are three fundamental differences:

If most members want the full namespace rename, it's difficult to understand why that hasn't happened then. But...

 

- javax was effectively legally blocked, meaning that renaming was the only way to move forward.

- While Microprofile is considerably smaller than Jakarta, there are also fewer resources working on the project today than when we first started, so who is going to do the work? Remember that this also affects implementations and consumers. We had a justification before (see previous bullet), but now I don’t see a good justification for something that will bring zero short-term value to users, and long-term value is still to be determined.

- The javax to jakarta was essentially only a rename. Here we have a merge with a possible rename, which opens up a lot of unanswered questions (at least in my mind; maybe for others these are clear):

- Should we keep MP Config or go with a new Jakarta Config?

- Should we keep JWT, or should it be merged with Jakarta Security / Authentication / Authorization?

- Should we keep REST Client and OpenAI, or should they be merged with Jakarta REST

- Should we keep Reactive Messaging, or should it be merged with Jakarta Messaging?

- What about Fault Tolerance and Health? Keep them standalone? Or should they live in another Jakarta spec?

- What about deprecated OpenTracing and Metrics? Is there any point in those?

- And many other questions...

Pragmatically, MP should be merged into Jakarta as is, and then we can have these conversations and decide what to do with each spec. 

At this point I'm willing to agree with that. I've been working with/on J2EE/Java EE/MP/Jakarta EE for give or take 23 years now. In my case that amounted to 6, sometimes 7 days per week. We had our challenges and crises in the past, but this is the first time I'm really seeing a truly existential crisis. If we don't act now instead of bickering and discussing among ourselves, there will not be much left to bicker about in perhaps a year from now.

I'm less concerned about the exact details. With so few resources available, we simply don't have the luxury to spend endless time debating these issues. Let's move forward in whatever way we can.

We can rename (or not) and decide all those things you mention later. It's not unheard of. In EE and MP we rename, move, and refactor things too. Security is about to incorporate Authentication and Authorization, while Query Language has just been split out from Persistence, as Expression Language was once split out from Faces and Pages.

So yes, I agree, moving and deciding later is most likely the most optimal thing we can do at this point in time.

Kind regards,

Arjan Tijms

To view this discussion visit https://groups.google.com/d/msgid/microprofile/BA6D1295-619D-4FF4-8E8C-F6378E7BF26D%40yahoo.com.

[Kito D. Mann]

I have to say, that is the most pragmatic position I’ve heard since the whole debate began (again) last year.

 

We have already agreed in principle. Let’s just get it done, whatever offers the least path to resistance.

___

Kito D. Mann | @kit...@mastodon.social | LinkedIn | kitomann.bsky.social
Java Champion | Google Developer Expert Alumnus 
Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web Components, Angular, Mobile Web
Virtua, Inc. | virtua.tech
+1 203-998-0403

* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.

To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAGZXXAKDELWyBmmheO8cQ%3DPjwfqg3%2Bgx5H4exB3cj-pUwQZTUw%40mail.gmail.com.

[Roberto Cortez]

Hi,

On 11 Sep 2026, at 18:47, Arjan Tijms <arjan...@omnifish.ee> wrote:

On Fri, 11 Sept 2026 at 16:48, 'Roberto Cortez' via MicroProfile <microp...@googlegroups.com> wrote:

Hi Arjan,

I agree that we should have a unified group at this point.

I believe the big blocker is the namespace. I’ve read the past conversations, and most members are only willing to move forward with an all-or-nothing approach: merge, yes, but with a full namespace rename (microfile to jakarta).  We can argue that it was done before with javax to jakarta, but I believe there are three fundamental differences:

If most members want the full namespace rename, it's difficult to understand why that hasn't happened then. But...

To clarify, these were Jakarta members, not necessarly MP members. A merge proposal must come from MP. The last proposal from MP included a namespace retain, which most Jakarta members refused and pushed for a full rename:

https://www.eclipse.org/lists/jakarta.ee-spec/msg04220.html

Obviously, we are in a dead lock here. MP cannot force Jakarta to accept any terms, and when and if the merge happens, there is no way to guarantee that any terms are kept in place. The sentiment of the MP community in the last few years was to keep the namespace, while Jakarta was to absorb it. I’m only spearking for myself and not for the communities, but it is time to find some middle ground and leave idealisms aside and go with pragmmatic choices.

 

- javax was effectively legally blocked, meaning that renaming was the only way to move forward.

- While Microprofile is considerably smaller than Jakarta, there are also fewer resources working on the project today than when we first started, so who is going to do the work? Remember that this also affects implementations and consumers. We had a justification before (see previous bullet), but now I don’t see a good justification for something that will bring zero short-term value to users, and long-term value is still to be determined.

- The javax to jakarta was essentially only a rename. Here we have a merge with a possible rename, which opens up a lot of unanswered questions (at least in my mind; maybe for others these are clear):

- Should we keep MP Config or go with a new Jakarta Config?

- Should we keep JWT, or should it be merged with Jakarta Security / Authentication / Authorization?

- Should we keep REST Client and OpenAI, or should they be merged with Jakarta REST

- Should we keep Reactive Messaging, or should it be merged with Jakarta Messaging?

- What about Fault Tolerance and Health? Keep them standalone? Or should they live in another Jakarta spec?

- What about deprecated OpenTracing and Metrics? Is there any point in those?

- And many other questions...

Pragmatically, MP should be merged into Jakarta as is, and then we can have these conversations and decide what to do with each spec. 

At this point I'm willing to agree with that. I've been working with/on J2EE/Java EE/MP/Jakarta EE for give or take 23 years now. In my case that amounted to 6, sometimes 7 days per week. We had our challenges and crises in the past, but this is the first time I'm really seeing a truly existential crisis. If we don't act now instead of bickering and discussing among ourselves, there will not be much left to bicker about in perhaps a year from now.

Fully agree.

I'm less concerned about the exact details. With so few resources available, we simply don't have the luxury to spend endless time debating these issues. Let's move forward in whatever way we can.

We can rename (or not) and decide all those things you mention later. It's not unheard of. In EE and MP we rename, move, and refactor things too. Security is about to incorporate Authentication and Authorization, while Query Language has just been split out from Persistence, as Expression Language was once split out from Faces and Pages.

Certainly. Again, I’m not against renaming or moving things, but I will be against renaming without any clear plan on the final goal: As as example, if REST Client renames now, and then gets moves to Jakarta REST, you have to do two renames.

So yes, I agree, moving and deciding later is most likely the most optimal thing we can do at this point in time.

Fully agree again.

Is this something that other members are willing to move forward?

To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAGZXXAKDELWyBmmheO8cQ%3DPjwfqg3%2Bgx5H4exB3cj-pUwQZTUw%40mail.gmail.com.

[arjan tijms]

Hi,

To clarify, these were Jakarta members, not necessarly MP members.

Just a small clarification, aren't these largely the same people just wearing different hats? They are surely the same companies.

Kind regards,

Arjan Tijms

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/pPCM0ynBMDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/86A1EDC4-8875-4845-86E5-DF22ACBEC96B%40yahoo.com.

[Roberto Cortez]

Hi,

On 14 Sep 2026, at 12:24, arjan tijms <arjan...@gmail.com> wrote:

Hi,

To clarify, these were Jakarta members, not necessarly MP members. 

Just a small clarification, aren't these largely the same people just wearing different hats? They are surely the same companies.

Probably.

In any case, members that wanted to retain the namespace, came up forward with a proposal and a ballot (which failed). There was never an oficial proposal from a MP WG member to merge to Jakarta with the rename.

To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAE%3D-AhC7So3s1qz4mYoBPB2oi-ZnXTu_XDRdYOZQ92AC1oOTkQ%40mail.gmail.com.

[John Clingan]

There are still non-technical issues. Much of this deals with MP trying to govern itself closer to a traditional open source project under the umbrella of the Eclipse Foundation. Off top of my head:

1) Branding. Anyone can use MP logos and claim compatibility without being a WG member. EE requires WG membership to use compatibility logo.

2) Transparency. I brought up 2 years ago that EE marketing and steering committee calls are closed. Ed Bratt was going to work on opening them up to the community, but he is no longer with Oracle.

3) EE membership fees are way too high, IMHO. 

4) Jakarta feels too much like pay to play. Pay the fee, get a vote, get to use the compatibility logo.The orgs that do the work only get one vote.

[Arjan Tijms]

John,

Just wondering, but does any of what you say make a difference for Config, and somehow not for CDI and REST?

We're always busy revising and tuning the process, fee structure etc, but that discussion should be independent of the merge of Config etc into EE. Unless you really do have a reason why the fee structure is important for Config, OTEL, JWT, ... but not for CDI, REST and JSON.

Kind regards,

Arjan Tijms

To view this discussion visit https://groups.google.com/d/msgid/microprofile/6ecd1e72-3c8f-4e04-92df-453333856e8an%40googlegroups.com.

[John Clingan]

On Monday, September 21, 2026 at 5:31:11 AM UTC-7 arjan...@omnifish.ee wrote:

John,

Just wondering, but does any of what you say make a difference for Config, and somehow not for CDI and REST?

I think Jakarta would be better if it were more transparent, cost-effective, and more of a meritocracy, including CDI and REST specs.

 

We're always busy revising and tuning the process, fee structure etc, but that discussion should be independent of the merge of Config etc into EE. Unless you really do have a reason why the fee structure is important for Config, OTEL, JWT, ... but not for CDI, REST and JSON. 

See above. "Sunken cost fallacy" comes to mind.

[arjan tijms]

Hi,

On Mon, Sep 21, 2026 at 8:41 PM John Clingan <jtcl...@gmail.com> wrote:

I think Jakarta would be better if it were more transparent, cost-effective, and more of a meritocracy, including CDI and REST specs.

In what way is the Config spec a better spec than the CDI spec? Or, in what way is the Otel spec a better one than the REST spec? 

Kind regards,

Arjan Tijms

 

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/pPCM0ynBMDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/ad23b64d-3b2e-42b9-9948-dcacadb51e77n%40googlegroups.com.