[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-community] EE4J and the JCP
|
While the desire to create JCP.next is worth discussing I think the best venue for that discussion is the JCP EC.
While the key stakeholders here have interest in Java SE, ME, JavaFX, etc the key stakeholder that is missing is the core Java group of Oracle. I kind of doubt that part of Oracle will cede control in the way the Java EE part of Oracle has any time soon.
I think the wisest and most pragmatic move here is to do what is really right for Java EE. At best we can hope one day that will prove to pave the correct path for more parts of Java.
All that said, personally I am not that opposed to nominal JCP involvement, especially if it resolves the branding and naming issues.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Guillermo González de Agüero <z06.guillermo@xxxxxxxxx>
Date: 10/9/17 11:59 AM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] EE4J and the JCP
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
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 --------
Date: 10/9/17 10:59 AM (GMT-05:00)
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
_______________________________________________
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