Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Thanks Steve for writing this up. I completely agree and this has been my viewpoint on this matter for a while now.

All of what you pointed out is important, but these are the key points for me:

* Most developers that I have seen want us to focus on keeping the Jakarta EE namespace consistent.
* The broad perception is that Jakarta EE is focused on stability, backwards compatibility/longevity and relatively general use cases while MicroProfile is focused on innovation, experimentation and fine-grained microservices. This simple conceptual mapping is easy to express, understand and emphasizes harmonious co-existence. This mapping translates best to a dependency chain going in one direction, not a confusing circular dependency.
* In practice what we have seen during previous platform releases is that there is a high degree of feature, API, dependency and release schedule coordination between component specifications. This is very difficult to manage with essentially independent initiatives that have circular dependencies and different goals/release schedules.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: 1/14/21 5:04 AM (GMT-05:00)
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Subject: [cn4j-alliance] MP apis and "graduation" to Jakarta EE

I’ve thought a lot over the last year about the relationship of MP and Jakarta and how apis should be consumed for each. I just thought I’d put this down as a conversation starter from my vendor perspective.

 

So some overall statements.

 

  1. Jakarta EE should not use the MicroProfile namespace
  2. Jakarta EE should adopt MP apis by moving them into the Jakarta namespace when they are mature
  3. MP can choose to add the adopted api back into their platform just like Jakarta REST today or can continue to evolve the api in its own namespace.

 

Why do I think this?

 

Jakarta EE has a focus on backwards compatibility while MicroProfile has the goal of experiment and innovate without backwards compatibility. Moving a Jakarta adopted api into the Jakarta namespace means the Jakarta team can ensure backwards compatibility.

 

Prevents developer confusion. Developers can know that when they import an api in the Jakarta namespace they get stability and backwards compatibility and when they import an api in the microprofile namespace that it may change between major releases.

 

Vendors like Payara can more easily support both platforms. Take for example the case of where Jakarta EE wants to adopt MicroProfile Wombat 2.0 but MicroProfile WG wants to keep evolving MicroProfile Wombat 3.0 to a completely new api. By moving namespace and creating Jakarta EE Wombat 2.0 Payara can support both the latest MicroProfile Wombat 3.0 AND Jakarta EE Wombat 2.0 delivering the needs of the different developer communities.

 

Platform consistency – when moving an api into Jakarta EE it may need to be evolved to ensure it is consistent with the rest of the Jakarta EE platform e.g. supporting Jakarta Security etc. This is likely not possible in MP.

 

Easier demarcation between independent groups. The groups are independent of each other and this enables each group to be in control of its own platform without the need to maintain an LTS or Profile on one side just for the benefit of the other.

 

The alliance is then more about minimising duplication of effort when creating and evolving specification and deciding where the creation and maintenance of a specification should live.

 

Thanks

 

 

Steve

 

 

Back to the top