Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] MicroProfile use of Jakarta EE Specification Process

+1 

This is really a conversation for the MP community. Jakarta EE may leverage work done by the MP, but it's not our place on this specification body to determine the merits of having MP adopt the EFSP.  

On Thu, Feb 21, 2019 at 8:24 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Bill,
I was talking with Tanja and others at Think last week about this exact issue...  I have a TODO to perform a thorough review of the proposed process and how it might or might not work with MicroProfile.  But, only speaking for myself (not the whole community), I don't see how the EFSP nor the JESP will allow the MicroProfile community to continue to drive innovation at a sufficient pace to keep up with our past history.  Yesterday's discussion even cemented some of those views.  We were talking about minimum or maximum amount of time for each of the review cycles.  At one point, we discussed how did the JCP do it.  If we fall back to the JCP rules all the time, we've lost (imho).  The JCP worked back in its day, but given the industry today, I don't see how it can thrive.  Granted, the stream-lined JCP that is in place for the quicker paced Java SE releases is better.  But, most of the experiences that we discuss in these Jakarta EE calls relates back to the old mechanisms.

(Aside...  Maybe we need to look at how Java is doing releases every 6 months...  JEPs seem to be pretty easy to get through the process, and then a JSR is used to actually push through the next Java 11, 12, xx release.  That's my 10,000 foot view of the process.  Do we need to look at something like this?)

So, could MicroProfle utilize the EFSP and/or JESP as currently defined?  I doubt it.  Not for the many component and platform releases that the MicroProfile community has produced.  In just over two years, we have produced 22 component releases (ie. MP Config 1.x, MP Fault Tolerance 2.x, etc) and 8 platform releases (ie. MicroProfile 1.x, 2.x).  Given the required timelines that we discussed yesterday, there is no way we could have done all of this in two years.  Going forward, we are looking to produce three MicroProfile platform releases per year (Feb, June, Oct) with several component releases through out the year.  Some of these component releases are stand-alone and some are part of the platform.

Besides the MicroProfile question, we also have to look at this from a competition viewpoint.  We have stated that Jakarta EE is the new home for Cloud Native Java.  My anecdotal evidence from speaking at and soliciting comments from many conferences is that Spring is still the king of Cloud Native Java.  We are going to have to figure out how the JESP will allow Jakarta EE to compete with Spring.  MicroProfile is making some inroads on this front, but we're still small potatoes compared to Spring's presence -- especially in production environments.  I think we're making good progress with development environments, but production is still behind.  If MicroProfile is "forced" to use the JESP (as currently defined), then I think we lose this race as well.

Another thought...  I know MicroProfile has some IP issues to deal with.  I've talked with several people that indicate that we need to do something in this area to protect the IP rights for the MicroProfile community.  But, why does resolving this IP issue mean that MicroProfile has to adopt the EFSP/JESP?  Rather than whether MicroProfile should adopt the EFSP/JESP, I think the real question is whether another derivation (MicroProfile Spec Process?) could be developed to allow our community to continue to move forward and have our IP rights protected?  Currently, that's not allowed since MicroProfile is not part of a Working Group.  Maybe that needs to be re-addressed...

This note is getting much longer than I anticipated...  But, you can see that I've been thinking about this.  I just haven't put pen to paper yet...  I have several other thoughts related to this whole effort and how it affects both Jakarta EE and MicroProfile.  But, let's start with this initial thought dump and see where it goes...

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        Bill Shannon <bill.shannon@xxxxxxxxxx>
To:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        02/20/2019 03:33 PM
Subject:        [jakarta.ee-spec.committee] MicroProfile use of Jakarta EE        Specification Process
Sent by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx




Just a reminder that I'll still waiting for feedback on this issue:
I'd like to get an assurance from each MicroProfile participant that the JESP would be suitable for MicroProfile, and if not exactly what changes would be required to make it so.
Note that I'm not asking you to speak for the MicroProfile community as a whole.  I just want to know from each of you (who participates in the MicroProfile community) if you would support the MicroProfile community using the Jakarta EE Specification Process.
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee



_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


--

Back to the top