| Re: [ee4j-community] EE4J and the JCP |
Hi, It is not up to the JCP if a JSR takes longer or not. Michael himself knows best, how JSRs can turn into a Never-ending-story as it did with JSR 310: https://jcp.org/en/jsr/detail?id=310 Over 7 years from Creation Review to Final Relaase, and it was only Oracle who stepped in as Co-Spec Lead and made the Java SE 8 integration possible. Otherwise the JSR would likely have failed or be dormant now. Take two other examples of updated specs led by MicroProfile activist companies IBM and Red Hat: https://jcp.org/en/jsr/detail?id=362 Took over 4 years and 2 Renewal Ballots which are already there to make the JCP and JSRs more effective. The Spec Lead seems (like many, we see that a lot with Oracle and the Java EE 8 Spec Leads) to have had only part of his time to drive the spec. And except one other Portal vendor (Liferay) there was not a lot of contribution from EG members either. I was on the EG and helped with architectural aspects, Integration with CDI, etc. but I am not a Portal vendor myself so my Involvement was always more that of an expert Consultant using the Technology. As a contrast another JSR that I was also in the EG, Bean Validation 2.0: https://jcp.org/en/jsr/detail?id=380 Which finished in a record time of just about a year since creation. Obviously Gunnar, who beside leading his JSR also found time to help e.g. MicroProfile Config and other efforts, had the freedom to Focus on his spec without being entangled into sales pitches or customer Support etc. It is usually a matter of the right Spec Lead(s) and EG Members, if a JSR gets on well or delayed. The JCP even the PMO have very Little Impact on that. In a few cases like JSR 377 which also seems more comparable to cases where the Spec Lead has too many other Things to do (either corporate duties or other Open Source Projects) the EC threw a lifeline of Renewal Ballot twice. And fortunately there seems a bit of momentum, though it remains to be seen, if industry Players and Projects from Eclipse RCP to NetBeans really want that Kind of Thing standardized beyond what each of them already got. Werner From: ee4j-community-request@xxxxxxxxxxx Send ee4j-community mailing list submissions to ee4j-community@xxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community or, via email, send a message with subject or body 'help' to ee4j-community-request@xxxxxxxxxxx You can reach the person managing the list at ee4j-community-owner@xxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of ee4j-community digest..." Today's Topics: 1. Re: EE4J and the JCP (Kevin Sutter) 2. Re: EE4J and the JCP (Michael Nascimento) ---------------------------------------------------------------------- Message: 1 Date: Mon, 9 Oct 2017 09:59:50 -0500 From: Kevin Sutter <kwsutter@xxxxxxxxx> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx> Subject: Re: [ee4j-community] EE4J and the JCP Message-ID: <CABH8erkGu3oou+XO1tj-=Kjsbya-o2zu_3o3w6nzT8eicKiecQ@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8" I can understand Michael's and others concerns voiced in this thread... Splintering the Java community is definitely not a goal of this EE4J movement. But, the JCP has not demonstrated that it can move faster. Yet... Granted, there is a requirement for Java SE to have it move faster to meet the newly proposed 6 month cycles, but it hasn't been proven yet. The MicroProfile community has shown that it can innovate on a faster schedule with it's recent MP 1.1 and 1.2 releases. I'm not trying to say that the MicroProfile efforts produced "standards", but I am noting that innovation needs a lighter weight process in order to compete and succeed in this cloud-native, microservices world. The specification process in EE4J has not been determined yet. Maybe if the JCP proves that it can process JSRs in a more expedient manner, then maybe it can or will be considered as part of the EE4J specification process. In the mean time, we have to leave other options on the table. -- Kevin On Mon, Oct 9, 2017 at 5:04 AM, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote: > Hi All, > > I can clarify some of this. Responses inline > > On 9 October 2017 at 10:00, Guillermo Gonz?lez de Ag?ero < > z06.guillermo@xxxxxxxxx> wrote: > >> Hi, >> >> As I said on Markus thread, my concern is that we might not be moving >> Java EE to a different place, but discontinuing Java EE and creating a new >> project based on it. On that matter, we'll need clarification from Oracle >> and the participating vendors: are you really open sourcing what's already >> there, or are you making Java slimmer by moving away everything but the >> standard edition? In the second case (which I hope is not the case), I'd >> sadly understand that a common standards body wouldn't make sense. >> >> The JCP process has been blamed for being too slow, but how will it allow >> Java SE to release a new version every 6 months? Surely that will need some >> changes on the JCP. Could those changes also help us? Should we participate >> on those discussions asking for our needs? >> > > Yes the JCP is altering its process, primarily cutting down the minimum > and maximum times for various phases and voting periods. This is being > worked on in conjunction with the folks from OpenJDK and Oracle and I > everyone is comfortable with the changes being proposed (just needs to go > through various votes to pass). > > >> In my opinion it's still too early to abandon the JCP. We should see >> before if it can still be changed to take everyone's concerns into account >> (Java SE, Java ME and Java EE) and in case it's too difficult, I'm with you >> and Markus, we should create a common replacement. >> > > I think the EE4J community will need to define a *vendor neutral* body to > effectively replace the JCP with regards to defining specifications and > certifications for whatever the community produces. > > The JCP is the best construct we could have at the time. But because it is > 'heavily influenced' by a single vendor (Oracle) it's simply not the true > neutral body that we all want going forwards. That's not to say that the > JCP and/or Oracle did a bad job in stewarding Java EE / Enterprise Java, > but a more open body will certainly be an improvement. > > >> PS: could you please point me to some link on the Java ME movement you >> mention? I haven't found any information about it. >> > > Gluon, V2Com and other ME companies are trying to get ME kick started > again. please contact pmo@xxxxxxx to get involved. > > Cheers, > Martijn (London Java Community - JCP EC member) > > > > >> Regards, >> >> Guillermo Gonz?lez de Ag?ero >> >> El lun., 9 oct. 2017 a las 4:19, Michael Nascimento (<misterm@xxxxxxxxx>) >> escribi?: >> >>> Consolidating my thoughts here with the correct thread name: >>> >>> My main concern is that, while we might be doing something better suited >>> for the Java EE community, we're scattering the Java community even more. >>> OpenJDK has its own contribution agreements, rules and process; we're about >>> to create something different here; everything else left in the JCP will >>> follow the current process; apparently Java ME wants to do something >>> similar to EE. So this new reality will mean one's contributions to one >>> part of Java means nothing when they contribute to the rest, there'll be a >>> lot to learn process-wise, paperwork to be filled... We're actually making >>> it harder for people to contribute to Java *in general*. >>> >>> While I understand OpenJDK is kind of a "sideways" situation, I'd like >>> to propose we pursue something here in terms of specification process that >>> can be used for all Java specifications in the future that find the JCP too >>> heavyweight and problematic, so that we don't have one solution for every >>> facet of Java. Something like "Open Standards for Java". If key players as >>> IBM, Red Hat, Tomitribe et al and some communities, as the LJC, conclude >>> the JCP is not the way to do things going forward, I'm making a plea for >>> JCP.next to be established here - and not just EE4J spec process; >>> otherwise, we're fragmenting the community even more and making >>> contributions to Java, as a whole, even more painful. >>> >>> To Mike Milinkovich, following up the question I've made: if the >>> Eclipse Foundation is the one submitting the JSRs, wouldn't all IP from the >>> specs belong to the Foundation? Wouldn't it be open and egalitarian? >>> >>> Regards, >>> Michael >>> _______________________________________________ >>> ee4j-community mailing list >>> ee4j-community@xxxxxxxxxxx >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/ee4j-community >>> >> >> _______________________________________________ >> ee4j-community mailing list >> ee4j-community@xxxxxxxxxxx >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/ee4j-community >> >> > > _______________________________________________ > ee4j-community mailing list > ee4j-community@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/ee4j-community > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171009/469eb96f/attachment.html> ------------------------------ Message: 2 Date: Mon, 9 Oct 2017 12:09:21 -0300 From: Michael Nascimento <misterm@xxxxxxxxx> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx> Subject: Re: [ee4j-community] EE4J and the JCP Message-ID: <CAAWA2oWmyXKm6CqSwn4irNmg-SuPc4zCwYpYYxGmy2hDa_rSpg@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8" Hi Kevin, I'm *fine* with having a new Java specification process. What I see as a major problem is having a new EE spec process, that is only applicable to EE, starting even with its name. So let's either embrace the JCP or strive for the JCP.next, because either option keeps the community together. Regards, Michael On Mon, Oct 9, 2017 at 11:59 AM, Kevin Sutter <kwsutter@xxxxxxxxx> wrote: > I can understand Michael's and others concerns voiced in this thread... > Splintering the Java community is definitely not a goal of this EE4J > movement. But, the JCP has not demonstrated that it can move faster. > Yet... Granted, there is a requirement for Java SE to have it move faster > to meet the newly proposed 6 month cycles, but it hasn't been proven yet. > The MicroProfile community has shown that it can innovate on a faster > schedule with it's recent MP 1.1 and 1.2 releases. I'm not trying to say > that the MicroProfile efforts produced "standards", but I am noting that > innovation needs a lighter weight process in order to compete and succeed > in this cloud-native, microservices world. > > The specification process in EE4J has not been determined yet. Maybe if > the JCP proves that it can process JSRs in a more expedient manner, then > maybe it can or will be considered as part of the EE4J specification > process. In the mean time, we have to leave other options on the table. > > -- Kevin > > On Mon, Oct 9, 2017 at 5:04 AM, Martijn Verburg <martijnverburg@xxxxxxxxx> > wrote: > >> Hi All, >> >> I can clarify some of this. Responses inline >> >> On 9 October 2017 at 10:00, Guillermo Gonz?lez de Ag?ero < >> z06.guillermo@xxxxxxxxx> wrote: >> >>> Hi, >>> >>> As I said on Markus thread, my concern is that we might not be moving >>> Java EE to a different place, but discontinuing Java EE and creating a new >>> project based on it. On that matter, we'll need clarification from Oracle >>> and the participating vendors: are you really open sourcing what's already >>> there, or are you making Java slimmer by moving away everything but the >>> standard edition? In the second case (which I hope is not the case), I'd >>> sadly understand that a common standards body wouldn't make sense. >>> >>> The JCP process has been blamed for being too slow, but how will it >>> allow Java SE to release a new version every 6 months? Surely that will >>> need some changes on the JCP. Could those changes also help us? Should we >>> participate on those discussions asking for our needs? >>> >> >> Yes the JCP is altering its process, primarily cutting down the minimum >> and maximum times for various phases and voting periods. This is being >> worked on in conjunction with the folks from OpenJDK and Oracle and I >> everyone is comfortable with the changes being proposed (just needs to go >> through various votes to pass). >> >> >>> In my opinion it's still too early to abandon the JCP. We should see >>> before if it can still be changed to take everyone's concerns into account >>> (Java SE, Java ME and Java EE) and in case it's too difficult, I'm with you >>> and Markus, we should create a common replacement. >>> >> >> I think the EE4J community will need to define a *vendor neutral* body to >> effectively replace the JCP with regards to defining specifications and >> certifications for whatever the community produces. >> >> The JCP is the best construct we could have at the time. But because it >> is 'heavily influenced' by a single vendor (Oracle) it's simply not the >> true neutral body that we all want going forwards. That's not to say that >> the JCP and/or Oracle did a bad job in stewarding Java EE / Enterprise >> Java, but a more open body will certainly be an improvement. >> >> >>> PS: could you please point me to some link on the Java ME movement you >>> mention? I haven't found any information about it. >>> >> >> Gluon, V2Com and other ME companies are trying to get ME kick started >> again. please contact pmo@xxxxxxx to get involved. >> >> Cheers, >> Martijn (London Java Community - JCP EC member) >> >> >> >> >>> Regards, >>> >>> Guillermo Gonz?lez de Ag?ero >>> >>> El lun., 9 oct. 2017 a las 4:19, Michael Nascimento (<misterm@xxxxxxxxx>) >>> escribi?: >>> >>>> Consolidating my thoughts here with the correct thread name: >>>> >>>> My main concern is that, while we might be doing something better >>>> suited for the Java EE community, we're scattering the Java community even >>>> more. OpenJDK has its own contribution agreements, rules and process; we're >>>> about to create something different here; everything else left in the JCP >>>> will follow the current process; apparently Java ME wants to do something >>>> similar to EE. So this new reality will mean one's contributions to one >>>> part of Java means nothing when they contribute to the rest, there'll be a >>>> lot to learn process-wise, paperwork to be filled... We're actually making >>>> it harder for people to contribute to Java *in general*. >>>> >>>> While I understand OpenJDK is kind of a "sideways" situation, I'd like >>>> to propose we pursue something here in terms of specification process that >>>> can be used for all Java specifications in the future that find the JCP too >>>> heavyweight and problematic, so that we don't have one solution for every >>>> facet of Java. Something like "Open Standards for Java". If key players as >>>> IBM, Red Hat, Tomitribe et al and some communities, as the LJC, conclude >>>> the JCP is not the way to do things going forward, I'm making a plea for >>>> JCP.next to be established here - and not just EE4J spec process; >>>> otherwise, we're fragmenting the community even more and making >>>> contributions to Java, as a whole, even more painful. >>>> >>>> To Mike Milinkovich, following up the question I've made: if the >>>> Eclipse Foundation is the one submitting the JSRs, wouldn't all IP from the >>>> specs belong to the Foundation? Wouldn't it be open and egalitarian? >>>> >>>> Regards, >>>> Michael >>>> _______________________________________________ >>>> ee4j-community mailing list >>>> ee4j-community@xxxxxxxxxxx >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community >>>> >>> >>> _______________________________________________ >>> ee4j-community mailing list >>> ee4j-community@xxxxxxxxxxx >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/ee4j-community >>> >>> >> >> _______________________________________________ >> ee4j-community mailing list >> ee4j-community@xxxxxxxxxxx >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/ee4j-community >> >> > > _______________________________________________ > ee4j-community mailing list > ee4j-community@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/ee4j-community > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171009/a8eedb1f/attachment.html> ------------------------------ _______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community End of ee4j-community Digest, Vol 2, Issue 41 ********************************************* |