On 2018-01-16 3:59 PM, Guillermo
González de Agüero wrote:
And
that's great. A new process with the spirit of the JCP, but
without its lacks. I have no doubt this move will be beneficial
for everybody.
But I can't consider it a JCP replacement (in the sense of
the home for Java standards) if it lacks former privileges.
There's where my doubts lay.
There, at its heart is the dilemma. "I have no doubt this move will
be beneficial for everybody....except I will doubt anything that
changes." (If you will pardon the paraphrasing.)
Sadly, we cannot have our cake and eat it too.
I understand that it would be wonderful if we could construct a
scenario where we had every single good thing about the status quo,
coupled with the goodness that will come from being open and
vendor-neutral. Unfortunately, that cannot happen for the reasons
Will explained in the initial email in this thread. Switching from
single vendor to multi-vendor does come with some unavoidable
changes. Everyone involved in this is working very hard on ensuring
backwards compatibility, and keeping changes to the bare minimum.
But some changes cannot be avoided.
On
2018-01-16 3:39 PM, Guillermo González de Agüero wrote:
> If the JCP doesn't fit the needs of Java EE nomore,
then go *replace* it.
That is exactly what is happening here.
The Eclipse Foundation is going to be creating a new
specification
process which will replace the role of the JCP as it
currently pertains
to Java EE. That new spec process will hopefully fix many
of the issues
with the JCP. I can guarantee that it will not have the
existing "get
all the IP" Spec Lead role. Similarly I can guarantee that
it will not
have any special votes or roles for Oracle or any other
special company.
|