Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-wg] Proposal on Jakarta EE’s innovation & relationship w/ MP

I have stated this before, but perhaps it bears repeating just one more time. For many users of Java EE, the key concern is whether the same set of stakeholders can successfully invest in two separate efforts that look a lot alike. If they cannot and need to pick winners and losers, the situation looks ugly fast to most potential adopters. That is why it is best to make these decisions sooner rather than later, really listen to what the broader community wants and make changes even if they are painful to some right now.

It is not too far fetched to observe that the key problem with Java EE and the JCP was not process - it was levels of investment, commitment and motivation. After all, Java SE does not seem to be having much issues with either cadence or utilizing an effective incubation process under the JCP these days.

Peace.

Reza Rahman
Principal Program Manager
Java on Azure

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

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

-------- Original message --------
From: Ken Finnigan <ken@xxxxxxxxxxxxxx>
Date: 7/24/19 11:07 AM (GMT-05:00)
To: Jakarta EE Working Group <jakarta.ee-wg@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-wg] Proposal on Jakarta EE’s innovation & relationship w/ MP



On Wed, Jul 24, 2019 at 9:06 AM Sebastian Daschner <mail@xxxxxxxxxxxxxxxxxxxxxx> wrote:
How would MicroProfile stay “as it is today”, when you’re proposing moving basically every spec currently in MicroProfile to JakartaEE?
I meant this as opposed to the idea of transforming MP to an / the incubator for Jakarta, which is an idea that quite a few in the community share / shared (including myself: [1]). I claim there is a need for a "rebase" process, i.e. to integrate updates to the specifications such as CDI or Concurrency back to Jakarta EE. For now, these updates and innovation happen in MP. Integrating / merging / porting these ideas to Jakarta leaves MP intact w/r/t branding, or production-readiness, which is where a few in the community have expressed their concerns with, and where I do think this is valid. This is why this proposal emerged at JCrete, and what I wanted to say with MP stays "as it is today". Most of us are active in both MP & JKEE, and from a technical perspective I don't see much collision nor competition, however, I claim this proposal puts the least "risk" to the MP community and brand.

I still don't see how your proposal leaves MP "as it is today" for several reasons.

You've proposed several specs from MP move over to Jakarta. Doing that means no work can happen in MP for those specs anymore otherwise it results in diverging specifications. When a Jakarta release is available for those specifications MP would need to discard it's own version and use the Jakarta one, which would result in a Jakarta EE 9 style package rename headache for MP users every single time there was a new MP release that contained a switch from an MP to Jakarta spec of the same thing.

For another group of MP specifications you've proposed making them "Jakarta EE Incubators". This appears even worse than Jakarta just taking the specification from MP, as not only do we get diverging specifications, but an indeterminate amount of time whereby Jakarta EE and MP are developing and releasing the same thing until such time as it no longer incubates in Jakarta and MP needs to replace to use that version, and we're back to a Jakarta EE 9 style package rename for users.

What does that leave MP to do? It essentially means it can only develop new specs, as everything else is in Jakarta EE. That's not exactly leaving MP "as it is today", unless the statement is meant as "MP stays as is with the spec versions it has today and no longer improves or innovates, and doesn't produce new releases".

Your proposal also completely ignores the differences in the specification model. Sure the Jakarta EE processes are going to be lighter than the JCP, but my understanding is they will still be a lot heavier than MP today.

Realistically, until Jakarta EE can show regular releases, and specify a cadence (which I don't think has been defined), any talk of moving anything from MicroProfile to Jakarta EE is premature in my view. Today MP is putting out three releases a year with anywhere from 2-5 updated/new specifications in each of those, and we've seen the usage and success grow dramatically over the last couple of years. Why would the MP community put all that at risk for such an unproven release schedule?

I firmly believe that Jakarta needs to show some successful releases and plans around dealing with more traditional specifications before there should be any thought of how MicroProfile might fit into that picture.
 


In this case, single-threaded is best because the focus needs to be on the successful release of Jakarta EE 8. What would be the point of having this discussion now if Jakarta EE 8 release is postponed or doesn’t happen? We need to discuss this topic when the time is right.
Could you please elaborate that? I don't see how such a conversation is putting the release of Jakarta at risk, or how it changes things whether Jakarta EE 8 happens tomorrow or next month? Actually I see quite the opposite: If we would come up to an agreement on the mechanics of such as process, regardless of the current legal / political situation, this would potentially even enable to get some initial work done, e.g. define what first incubation projects could include. The industry would then see more progress and that things are advancing which IMO adds more to the success of Jakarta rather than waiting for much longer (which I claim come with the danger of even more companies migrating away). I'd like to understand where these two things are technically constrained to not move on in a multi-threaded way.

Thanks for all your responses, highly appreciated.

Sebastian

On Wed, Jul 24, 2019 at 1:54 PM Cesar Saavedra <csaavedr@xxxxxxxxxx> wrote:
Sebastian, the topic of your proposal has been discussed at length before by members of both  Jakarta EE and MicroProfile. It’s a topic that’s in the parking lot that needs to be picked up by both communities once Jakarta EE 8 is successfully out. In this case, single-threaded is best because the focus needs to be on the successful release of Jakarta EE 8. What would be the point of having this discussion now if Jakarta EE 8 release is postponed or doesn’t happen? We need to discuss this topic when the time is right.

Reza, could you please refrain from amplifying Sebastian’s post via the Java Guardians until both communities can allocate time to discuss this topic in the future?

My fear is that your present efforts on this topic, although well intended, may negatively affect the success of both projects. And my feeling is that now is not the right time to take on this topic.

Thank you,
Cesar

On Wed, Jul 24, 2019 at 7:08 AM Ken Finnigan <ken@xxxxxxxxxxxxxx> wrote:
How would MicroProfile stay “as it is today”, when you’re proposing moving basically every spec currently in MicroProfile to JakartaEE?


Sent from my iPhone

On Jul 24, 2019, at 02:02, Sebastian Daschner <mail@xxxxxxxxxxxxxxxxxxxxxx> wrote:

While the current heads down focus is Jakarta EE 8, I fully agree with you there is no real way of deferring this discussion in the broader community.
Thanks, this was exactly my motivation why I wanted to start this conversation now. I understand that there is a lot of urgent work in the pipeline, however, in a single-threaded model, things will take quite a bit of time :)

Regarding the MicroProfile community: This was actually the idea why the proposal suggests that MP stays as it is today, in order to keep the branding, community, etc. intact.

Sebastian 

On Wed, Jul 24, 2019 at 3:40 AM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
I have to say this is just awesome. Thanks for doing this. Do you mind if I propose that the Java EE Guardians republish this content and amplify it?

While the current heads down focus is Jakarta EE 8, I fully agree with you there is no real way of deferring this discussion in the broader community. Everybody wants to know what happens the day after Jakarta EE 8. Might as well start somewhere and this looks like a pretty good starting point to me in terms of getting people thinking.

Cheers,
Reza Rahman
Principal Program Manager
Java on Azure

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: Sebastian Daschner <mail@xxxxxxxxxxxxxxxxxxxxxx>
Date: 7/23/19 3:12 AM (GMT-05:00)
Subject: [jakarta.ee-wg] Proposal on Jakarta EE’s innovation & relationship w/ MP

Hi there,

At the JCrete unconference, a few of us were brainstorming about the vision of Jakarta EE and especially the relationship with MicroProfile. I wanted to start that discussion in order to get everybody on the same page especially how the relationship between Jakarta EE and MicroProfile, and Jakarta’s innovation should look like. I believe that a lot of us agree on things already, however, I believe it would accelerates the process if we start that discussion.

I've created a blog post [1] on this topic which I wanted to cross-post here on this list. Feel free to forward or redirect me to a different mailing list that potentially fits better.


The following is a proposal on the bigger picture of the Jakarta standardization process, the relationship with MicroProfile, and the fact that there is a need for an incubation process. Please note that everything is up for discussion. My original view was to use MicroProfile as an incubator for Jakarta [2], however, some folks within the community have expressed their concerns with that idea since the MicroProfile brand gets more and more established and is seen as more than just an incubator technology.

Motivations & reasoning

- There is a huge need to advance and innovate on Enterprise Java. Also, we need the possibility to innovate and discard some of the innovation without being carved in stone in standards, already.
- We need a process to rebase the incubators on the baseline, in order to use updated APIs from other specifications.
- We need an umbrella that ensures that multiple technologies work well together. The incubator projects need to work well with the baseline specifications as well.
- We need to make it as easy as possible for end users to use Jakarta EE and its incubators and to update to newer versions once things get incorporated into the baseline.
- We need to agree on the details of incubators and standards, regarding format and contents of technical documentation, examples, and Java packages.
- MicroProfile is establishing its brand and ecosystem which is seen as production-ready technology (more than just an incubator) and which is something we might want to keep.
- We might want to start these considerations now, in order to align stakeholders and to decide what the picture looks like, even things only get realized weeks and months from now.

Proposed process

- The Jakarta umbrella contains specifications that are part of the baseline (which corresponds to the Java EE umbrella).
- Jakarta incubators are the typical way to innovate and advance Jakarta in newer technologies. Published versions of incubators can be used in combination with the Jakarta baseline, and offer a quicker way to implement and discard things.
- Jakarta incubators are based on a specific version in the baseline branch and can and should re-use the technology contained in the baseline. Incubators use the same design principles and the jakarta Java package in order to make it easy for early adopters to switch from incubator dependencies to specifications.
- Longer-running Jakarta incubators can and should be rebased to a recent Jakarta version in order to use the latest technology and to facilitate usage for implementers and users.
- Jakarta incubators that have proven themselves can get included into the baseline branch as proper Jakarta standards. In order to make that transition easier, incubators use the jakarta Java package and follow a certain (simplified) process on documentation, specification, and code examples. However, everything inside an incubator may change before transformed into a Jakarta specification.
- All Jakarta incubators and specifications need to provide a specification, targeted to implementers and users, as well as documentation and getting-started code examples on commonly-used patterns, targeted to users. The documentation must include a short motivation why and in which cases the technology is required, and enable users without prior knowledge to get started quickly.
- The MicroProfile brand and ecosystem stays as is and can continue to evolve as is with all its current projects. Jakarta incorporates the efforts and innovation that already happened within MicroProfile, with adaptions where required. Once Jakarta includes new specifications, for example Config, it might make sense to rebase MicroProfile to then include these new standards instead of its current projects.

Diagram



I propose to advance the future of Jakarta EE with the following technology:

New standards in Jakarta EE

- Configuration (Jakarta-Config) will be a new specification project in the Jakarta baseline. It originates from the efforts behind the withdrawn Config JSR, and MicroProfile Config.
- Model View Controller (from JSR 371)
- JCache (from JSR 107)
- Deployment specifications: standardizing the way how to deploy and modern apps, how to provide libraries, what the runtime directory layout looks like, thin deploy artifacts, etc.

Updates on EE standards

- Concurrency: incorporating approaches from mp-context-propagation and bulkheads from mp-fault-tolerance
- Security: incorporating approaches from mp-jwt-auth
- JAX-RS: incorporating approaches from mp-rest-client where reasonable

New incubators in Jakarta EE

- Fault-tolerance: circuit breakers, timeouts, retries, fallbacks, features taken from mp-fault-tolerance
- Observability: features from mp-metrics, mp-open-tracing, mp-health
- Testing: incorporating ideas and approaches from Arquillian, Spring Test, Testcontainers, and maybe more
- Reactive-streams / messaging: features taken from mp-reactive-streams and mp-reactive-messaging
- LRA (or different name): approaches taken from mp-lra
- Open API: features from mp-open-api


As always, anything is up for discussion. WDYT?

Sebastian

[2] https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
--
Cesar Saavedra
Senior Principal Technical Product Marketing Manager
(407) 492-9801
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg

Back to the top