[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-community] EE4J and the JCP
|
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