| Re: [ee4j-community] EE4J and the JCP |
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@eclipse.org
You can reach the person managing the list at
ee4j-community-owner@eclipse.org
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 (Martijn Verburg)
2. Re: EE4J and the JCP (Steven Pousty)
------------------------------------------------------------ ----------
Message: 1
Date: Mon, 09 Oct 2017 16:17:29 +0000
From: Martijn Verburg <martijnverburg@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>,
spousty@xxxxxxxxxx
Subject: Re: [ee4j-community] EE4J and the JCP
Message-ID:
<CAP7YuARM6XA5GYahCGbdWODNPxq9HwiTSRZj5L8ucjhC6pZoLw@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
This is actually how microprofile works today and dare I say it seems to
have proven itself. I?m hopeful that this new community will want to run
in a similar manner. It seems to be a good trade off
On Mon, 9 Oct 2017 at 17:08, Steven Pousty <scitronp@xxxxxxxxxx> wrote:
> I would really like to see us move more to "innovation" model where
> vendors collaborate on technology they want to move forward. When the tech
> starts to bake and gets "finished" then it moves to a spec.
>
> I would like to see Java move from something driven by large vendors to
> more of a community-based innovation model, where large vendors are part of
> that community.
>
> I know a bunch of people will bristle at this idea, it is very different
> than how things have been done. But without this innovation in the way
> things get done, Java will continue to be seen as the slow, dying platform
> for greenfield projects.
>
>
>
> On Mon, Oct 9, 2017 at 8:59 AM, Guillermo Gonz?lez de Ag?ero <
> z06.guillermo@xxxxxxxxx> wrote:
>
>> But creating a new standards body that fulfils the requirements of other
>> Java specs will also need a lot of work.
>>
>> I'm not against the idea of creating a new standarization process, but
>> the JCP still provides us some benefits like the use of the Java name and
>> packages. I'd personally don't create a new system while those issues are
>> not resolved.
>>
>> The Config JSR will be a good experiment of the MicroProfile style of
>> defining a spec on its own and then moving it to the JCP just for
>> standarization purposes.
>>
>> I believe that approach could work for us *while* we define a new system.
>> Rushing to create a new body will probably make us fail and fragment
>> community.
>>
>> Some kind of EG and process will be needed in the meantime but
>> MicroProfile has shown us that progress can be fast yet solid with little
>> bureaucracy. A new JCP.next can be created in parallel.
>>
>> Maybe private discussions are already taking place on this subject. Some
>> overview of the ideas and intentions would be appreciated.
>>
>>
>> Regards,
>>
>> Guillermo Gonz?lez de Ag?ero
>>
>> El lun., 9 de octubre de 2017 17:38, reza_rahman <reza_rahman@xxxxxxxxx>
>> escribi?:
>>
>>> I agree with Kevin's assessment on this. Efficiency is also just one
>>> issue at the JCP. The bigger issue is direct and indirect Oracle control,
>>> especially at the EC level. While these are solvable problems, the question
>>> we should ask is whether it is worth solving instead of using avenues that
>>> are already far more vendor neutral.
>>>
>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>>
>>> -------- Original message --------
>>> From: Kevin Sutter <kwsutter@xxxxxxxxx>
>>> Date: 10/9/17 10:59 AM (GMT-05:00)
>>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>>> Subject: Re: [ee4j-community] EE4J and the JCP
>>>
>>> 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
>>>
>>
>> _______________________________________________
>> 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
>
--
Cheers, Martijn (Sent from Gmail Mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20171009/22a7fcf3/attachment. html
------------------------------
Message: 2
Date: Mon, 9 Oct 2017 09:22:33 -0700
From: Steven Pousty <scitronp@xxxxxxxxxx>
To: Guillermo Gonz?lez de Ag?ero <z06.guillermo@xxxxxxxxx>
Cc: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] EE4J and the JCP
Message-ID:
<CAOQvhxQ=b7Pgw3sG-Tfca1OS=AOa8=2g8p8QX0ovyFXxdfatFA@ mail.gmail.com >
Content-Type: text/plain; charset="utf-8"
You are completely right Java EE is not the place for that but EE4J is. The
time has come to move from Vendor Centered to Community Centered.
Actually it is EE4J that is moving to the same place as the microprofile
not vice versa.
On Mon, Oct 9, 2017 at 9:16 AM, Guillermo Gonz?lez de Ag?ero <
z06.guillermo@xxxxxxxxx> wrote:
> Isn't MicroProfile what you are suggesting? They even made a little
> incompatible change on Config 1.1 for the sake of consistency and they have
> always been open to justified compatibility breaks.
>
> We definitely need some place to make that innovation, I just don't think
> Java EE as it currently is the right place for that. But if MicroProfile
> finally moves under the EE4J project, it would perfectly fit that need.
>
>
> Regards,
>
> Guillermo Gonz?lez de Ag?ero
>
> El lun., 9 de octubre de 2017 18:07, Steven Pousty <scitronp@xxxxxxxxxx>
> escribi?:
>
>> I would really like to see us move more to "innovation" model where
>> vendors collaborate on technology they want to move forward. When the tech
>> starts to bake and gets "finished" then it moves to a spec.
>>
>> I would like to see Java move from something driven by large vendors to
>> more of a community-based innovation model, where large vendors are part of
>> that community.
>>
>> I know a bunch of people will bristle at this idea, it is very different
>> than how things have been done. But without this innovation in the way
>> things get done, Java will continue to be seen as the slow, dying platform
>> for greenfield projects.
>>
>>
>>
>> On Mon, Oct 9, 2017 at 8:59 AM, Guillermo Gonz?lez de Ag?ero <
>> z06.guillermo@xxxxxxxxx> wrote:
>>
>>> But creating a new standards body that fulfils the requirements of other
>>> Java specs will also need a lot of work.
>>>
>>> I'm not against the idea of creating a new standarization process, but
>>> the JCP still provides us some benefits like the use of the Java name and
>>> packages. I'd personally don't create a new system while those issues are
>>> not resolved.
>>>
>>> The Config JSR will be a good experiment of the MicroProfile style of
>>> defining a spec on its own and then moving it to the JCP just for
>>> standarization purposes.
>>>
>>> I believe that approach could work for us *while* we define a new
>>> system. Rushing to create a new body will probably make us fail and
>>> fragment community.
>>>
>>> Some kind of EG and process will be needed in the meantime but
>>> MicroProfile has shown us that progress can be fast yet solid with little
>>> bureaucracy. A new JCP.next can be created in parallel.
>>>
>>> Maybe private discussions are already taking place on this subject. Some
>>> overview of the ideas and intentions would be appreciated.
>>>
>>>
>>> Regards,
>>>
>>> Guillermo Gonz?lez de Ag?ero
>>>
>>> El lun., 9 de octubre de 2017 17:38, reza_rahman <reza_rahman@xxxxxxxxx>
>>> escribi?:
>>>
>>>> I agree with Kevin's assessment on this. Efficiency is also just one
>>>> issue at the JCP. The bigger issue is direct and indirect Oracle control,
>>>> especially at the EC level. While these are solvable problems, the question
>>>> we should ask is whether it is worth solving instead of using avenues that
>>>> are already far more vendor neutral.
>>>>
>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>>>
>>>> -------- Original message --------
>>>> From: Kevin Sutter <kwsutter@xxxxxxxxx>
>>>> Date: 10/9/17 10:59 AM (GMT-05:00)
>>>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>>>> Subject: Re: [ee4j-community] EE4J and the JCP
>>>>
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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/6833bc78/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 48
*********************************************