Bootstrapping Proposals for Technical Alignment discussion #79
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| # MicroProfile and Jakarta EE Technical Alignment | ||
|
|
||
| MicroProfile was founded in 2016 as a compliment to Java EE, aimed at "driving innovation for future standardization" around microservices. Free from backwards compatibility, the vision was to provide a place where vendors and users combined can experiment, make mistakes, learn together, reinvent and reach stablization much faster. | ||
|
|
||
| The initial vision was proven APIs would be standardized via the JCP process. In August 2017 the Eclipse MicroProfile community submitted MicroProfile Config to the JCP as link:https://jcp.org/en/jsr/detail?id=382[JSR-382]. Quotes around the time reinforced the vision and anticipated relationship to the JCP. | ||
|
|
||
| - _"How we are collaborating in Open Source around this: Build a strong community; Collaborate on specifications; Encourage multiple implementations; Standardize technologies when ready"_ - John Clingan, 2019-07-07, link:https://developers.redhat.com/blog/2017/07/07/microprofile-optimizing-enterprise-java-for-a-microservices-architecture/[MicroProfile: Optimizing Enterprise Java for a Microservices Architecture] | ||
| - _"ideas that are rapidly prototyped in MP can quickly become standards via the JCP process and gain a larger audience"_, - Martijn Verburg, 2017-09-27, link:https://blog.payara.fish/microprofile-panel-one-year-on[MicroProfile One Year On] | ||
| - _"It was in our mission statement from the beginning that we would never subvert or undermine the JCP, but participate in it to accelerate innovation and standardization. By submitting this JSR, we are fulfilling that aspect of our mission statement."_ - David Blevins, 2017-08-23, link:https://adtmag.com/articles/2017/08/23/eclipse-microprofile.aspx[Eclipse MicroProfile 1.1 Paving a New Path for Java EE] | ||
| - _"The Configuration API JSR is based on innovation in the Eclipse MicroProfile Config project carried out by several contributors both corporate and individual ... with the hope of future standardization via the JCP."_ - Kevin Sutter, 2017-09-12, link:https://jcp.org/en/jsr/detail?id=382[JSR 382 Configuration API 1.0] | ||
|
|
||
| After the move of Java EE to Eclipse as Jakarta EE, similar thoughts were expressed. | ||
|
|
||
| - _"Since both MicroProfile and Jakarta EE are managed by Eclipse Foundation, the specifications defined under MicroProfile (e.g. MicroProfile Fault Tolerance) could be submitted to Jakarta EE and eventually standardized."_ - Emily Jiang, 2018-09-03, https://jaxenter.com/understanding-jakarta-ee-series-ibm-148922.html[Understanding Jakarta EE: “We can treat MicroProfile as a sports car and Jakarta EE as a minibus”] | ||
|
|
||
| The underlying consensus being that MicroProfile innovations are not standards. Users who use MicroProfile and vendors who implement it must understand the goal is not stability, but innovation. Breaking changes will occur. Innovation is prioritized over stability. | ||
|
|
||
| # Proposals for Standardization | ||
|
|
||
| After Jakarta EE 9 ships Jakarta specifications, which are standards, will want to benefit from the innovations of MicroProfile. The critical question is what is the 2020 answer for how a MicroProfile specification becomes a standard. | ||
|
|
||
| Proposals in discussion: | ||
|
|
||
| - link:proposal-microprofile-becomes-standards-initiative.adoc[MicroProfile becomes a standards initiative] | ||
| - link:proposal-specifications-graduation-to-jakarta.adoc[Innovations graduate to Jakarta] | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| # MicroProfile Becomes A Standards Initiative | ||
|
|
||
|
There was a problem hiding this comment. I feel Microprofile setting stable standards will naturally lead to competition with Jakarta EE. What if Jakarta EE doesn't want mixed package names do they just fork the MP standard into Jakarta EE and move namespace, now we have 2 "standards"? What if Jakarta EE likes some of the innovation e.g. Approaches taken in Reactive Messaging but not the specifics of the api do we again fork Reactive Messaging into Jakarta EE or try to change it in MP? |
||
| Under this proposal the concept of stable or "standard" specifications is introduced in order to keep APIs in the MicroProfile java package once they are deemed stable. | ||
|
|
||
| - API classes remain in `org.eclipse.microprofile` | ||
| - Once a specification is stable or "standard" it cannot be changed in a backwards-incompatible way | ||
| - some clear label or marker would need to be created to distinquish "standard" specifications | ||
|
There was a problem hiding this comment. Alternative: MP Specification can be moved to Jakarta, keeping the original package name. That way it is clear when it becomes a "standard" specification. MP umbrella still can combine spec from Jakarta and MP as it is now (with JAX-RS, CDI, ... coming from Jakarta ) There was a problem hiding this comment. All MP specifications we have today, are useful in todays 'enterprise' development, so not only for micro-services. This is also clear by the fact that all vendors included MicroProfile in their 'classic' Java EE product. There was a problem hiding this comment. Moving home is not trivial. I prefer the graduation in MP and mark it as standard. |
||
| - Only specifications that are marked "stable" or "standard" can be used in a Jakarta EE specification | ||
|
|
||
| When phrases like "innovation over stability" or "breaking changes are ok" are spoken, all community members must understand it does not apply to stable APIs. | ||
|
|
||
| # Long-term Effects | ||
|
|
||
| Under this proposal MicroProfile will become a predominately stable community. | ||
|
There was a problem hiding this comment. MicroProfile will still be the place where innovations happen. The MicroProfile umbrella can be seen as some kind of 'profile' (although not defined by Jakarta) so the pure MP implementation (like Helidon) can still have their place. |
||
|
|
||
| - Scenario 1: If a specification on average becomes stable in 2 years, with 8 new specifications added evenly over the next 4 years we would still be roughly 75% stable (16 total, 12 stable). From there 8 specifications added evenly over the subsequent 4 years we would be roughtly 83% stable and fairly large at 24 specifications. Under this scenario MicroProfile risks becoming bloated and not "micro" anymore. | ||
|
|
||
| - Scenario 2: If a specification on average becomes stable in 2 years, with 1 new specifications added evenly over the next 4 years we would still be roughly 83% stable (12 total, 10 stable). From there 4 specifications added evenly over the subsequent 4 years we would be roughtly 88% stable. | ||
|
|
||
| # Open Questions | ||
|
|
||
| * If a stable specification depends on a non-stable spec, how does that work? | ||
|
There was a problem hiding this comment. We need to differentiate between non-stable and backward incompatible. |
||
| * If MicroProfile needs to make a blanket breaking change (such as the recent pom discussion), how does that work? | ||
|
There was a problem hiding this comment. Is this about the 'standard' MP specifications or the 'innovation' specs? For 'standards' spec, something similar as Jakarta EE 9 can happen, otherwise the standards Semantic versioning rules apply. |
||
| * With both MicroProfile and Jakarta EE being focused on creating stable standards, the relationship between MicroProfile and Jakarta EE will become less clear. | ||
|
There was a problem hiding this comment. Not when Stable MP Specs are moved to Jakarta EE, then it is still clear (with MP Umbrella as some kind of 'Profile') |
||
| ** If you have a new idea where do you submit it? | ||
|
There was a problem hiding this comment. Feature of existing spec -> Jakarta EE |
||
| ** If if all unproven ideas are submitted in MicroProfile and never leave, how does Jakarta grow? | ||
| ** Will the intended synergy between the two become lost and eventually be two brands for the same inseparable thing? | ||
| * Does this create a circular dependency that could be difficult to manage? | ||
| * Could users find it difficult to understand which APIs are stable and when? | ||
|
There was a problem hiding this comment. This will be clear when we move MP stable specs to Jakarta EE. |
||
| ** "I see Metrics is stable, but I upgraded and my app broke.", "You're using Metrics 2.0. It didn't become stable till 3.0." | ||
| ** "In what version of MicroProfile did healthcheck become stable? Was it MP 4.0 or 5.0?", "I don't remember it's been 10 years." | ||
| * How does MicroProfile attract an audience promising both stability and instability/innovation? | ||
| * Will consensus become increasingly difficult as the focus of the committer base diverges into two camps; those who favor innovation over stability and those who favor stability over innovation. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| # Innovations Graduate to Jakarta | ||
|
|
||
|
There was a problem hiding this comment. This is my preferred approach. MP is upstream to Jakarta. Jakarta takes MP specs it wants, moves them to the jakarta namespace does any alignment and consistency work necessary to build a coherent jakarta platform and releases as Jakarta specs. I feel anything else will lead to tension. For example what is Jakarta EE needs changes to an MP spec to make it work better with a none MP spec where is the work done? Clear demarcation is the best option. |
||
| Under this proposal specifications ready for standardization are proposed as Jakarta specifications via Creation Review defined by the Jakarta EE Specification Process (JESP). | ||
|
|
||
| - API is repackaged into the `jakarta` namespace as currently defined by the Jakarta EE Specification Committee | ||
|
There was a problem hiding this comment. This will be very disruptive for the end users which are our main target. You simply don't do anything that harms your product. There was a problem hiding this comment. I actually think that makes sense. Take Config it is pretty stable I think it should be moved to jakarta and standardised in Jakarta EE 10. Similar for REST Client being part of Jakarta REST, Context Propagation should be part of the evolution of Jakarta Concurrency and Reactive Messaging (or something a bit like it) should become part of Jakarta Messaging. Yes it is partially disruptive but it fits the model MP break stuff and move fast and Jakarta stable specs. |
||
| - Vendors may ship and support the prexisting `org.eclipse.microprofile` package to provide optional compatibility | ||
| - Once a MicroProfile innovation is submitted and accepted (passes creation review), its Github repository is frozen | ||
|
|
||
| Pros: | ||
|
|
||
| - Consumers will have a clear rule to follow that stands the test of time | ||
| - Greater clarity in community goals helps consumers better understand Jakarta EE / MicroProfile relationship and synnergy | ||
| - Maximum ability to attract intended audience of those willing to try cutting edge apis and do not necessarily care about standards | ||
| - Less community conflict arising from those pursuing stability and those pursuing experimentation | ||
|
|
||
| Cons: | ||
|
|
||
| - MicroProfile will see change associated with adapting to package renames | ||
|
|
||
| # Long-term Effects | ||
|
|
||
| Number of projects could become very low at times. | ||
|
|
||
| # Open Questions | ||
|
|
||
| - When do we cut over to the `jakarta` version of the specification? | ||
|
There was a problem hiding this comment. After it has proven itself that it is useful and no major, disruptive changes will be needed anymore. This will always be a tricky decision. There was a problem hiding this comment. Probably pretty obvious based on level of innovation and churn in the API and also Jakarta has to want to accept it |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A third option is MP ceases to exist (as a package namespace) and Jakarta introduces a sandbox process where new apis can be experimented on and released before graduating to full stable specifications. Similar to how Java SE is handling things. All MP apis are moved to the jakarta namespace and future MP apis use the jakarta namespace from day one.