I agree with everything that Mark has written here about the
discussions around standards bodies.
My personal view is: I have been involved in the Java ecosystem
for at least 20 years. For that entire time there has been a
desire among many (not all) to have a vendor-neutral organization
as the steward of Java. For Java EE, that is going to be the
Eclipse Foundation. IMHO fracturing the role of steward across
multiple entities makes failure far more likely.
On 2018-01-17 6:17 AM, Mark Little wrote:
Hi Reza,
Thanks Mark for your response. I hope the
other key players will respect the legitimate desires
of the community enough to openly acknowledge it and
at least say they tried on their behalf if not to
preserve their own hard earned business interests and
investments.
On the note of moving forward, did you
notice my question with regards to standardizing via a
recognized body as opposed to simply the Eclipse
Foundation? I would love to understand your and Red
Hat's view on such a possibility.
I didn’t notice that, so apologies for only addressing a
portion of the thread.
When looking at where to move Java EE we (Oracle, IBM and
Red Hat) did touch on the standards body option. I’m sure I
wasn’t the only one, but I do recall raising the question
about OASIS specifically because I know Oracle, IBM, Red Hat
and others have worked together in OASIS many times over the
years. However, there was universal agreement that whilst
OASIS might be the right place for standards efforts such as
WS-*, TOSCA and other things which might well be considered
“protocol related”, it likely wasn’t the right place for Java
and Java EE related activities which are much more developer
focussed.
I also recall re-raising this with MikeM from Eclipse and
others once we had announced the move to the Eclipse
Foundation because clearly what we now have to do within
Eclipse is create processes which look very much like those
you’d find within an existing standards organisation, such as
OASIS or W3C. There are pros and cons with this but ultimately
the things which swayed me to say that we shouldn’t
standardise within OASIS or elsewhere include the following:
- having the code in Eclipse and standards efforts
elsewhere would mean individuals and corporations need to be
members of multiple (at least two) bodies. Whilst that might
not be too much of a hurdle for corporations, it’s not going
to be easy for some individuals and would be a possible
impediment to growing the community wide and deep.
- over the last 3 decades (ouch!) I’ve worked in pretty
much all of the standards bodies around and whilst they have
good processes for what they do, they’re not necessarily the
right processes for what the community may need around EE4J.
Furthermore, they don’t necessarily move quickly either. I
believe we can come up with a bespoke process within Eclipse
which feels more a natural part of the development effort than
something which is adjunct to it.
Not sure if this helps you and others, but you asked :)
Mark.
Sent via the Samsung Galaxy S7, an AT&T
4G LTE smartphone
-------- Original message --------
Date: 1/17/18 5:46 AM (GMT-05:00)
Subject: Re: [ee4j-community] Feedback
to Joint Community Open Letter on Java EE Naming and
Packaging
I’m fairly sure I’ve said this before on some lists and
also at JavaOne 2017 when we discussed some of this in
various meetings but I will repeat here: whilst I would
definitely have preferred to keep the javax namespace
for new specifications and to perhaps retain the Java EE
name for the branding, I understand Oracle’s position.
Related to that, I therefore know that no amount of
energy expended on trying to change these two things
will result in a different outcome. However, I think
what Oracle have done to this point in moving Java EE to
Eclipse is much more important than a brand name or a
Java package name and collectively we should expend that
energy in moving the code and community forward
collaboratively. EE4J will not fail because it’s not
branded Java EE. EE4J will not fail because new
specifications cannot be done under the javax package.
EE4J will fail if we spend too much time away from
driving these specifications forward and adding new
specifications to adapt to changes in the developer
space.
Therefore, whilst I understand what the
Guardians have requested, I feel that we are at a
point where we should focus on the positive aspects of
what Oracle have done and build on those. Together we
move EE4J forward and together we can make it a
success!
Mark.
Hello -
Reza Rahman has recently posted a Joint
Community Open Letter on Java EE Naming
and Packaging. Our feedback is given below -
most of it is context explaining our
direction. We hope it is helpful.
Oracle has previously
communicated that it intends to work with
the EE4J community to:
1) Define a branding strategy for
the platform, including a new name for
Java EE to be determined.
2) Enable use of existing javax
package names, and enable extension of
existing javax namespaces (e.g.
javax.servlet.*) to enable compatibility
and evolution of existing APIs.
3) Use a different namespace
naming convention, i.e. different from
“javax.*”, for net new APIs/technologies.
Note that doing the above remains
work in process, but it remains our
intent.
The open letter requests that
Oracle and other EE4J stakeholders work
together:
1) To allow the new platform to
retain the Java EE name
2) To allow use of existing
“javax” packages for existing
technologies
3) To allow use of the
“javax.enterprise” package for new
technologies
Oracle has already expressed its
intent to do what is requested in point #2
above. This would allow for
compatibility between EE4J releases and
existing Java EE releases at the package
level. We will focus on points #1 and #3
below. Why not allow use of the Java EE
name, and why not allow use of the
javax.enterprise namespace for all new
EE4J technologies?
The industry has changed since
the Java EE development process was
originally created. The process was not
seen as being nimble, flexible or open
enough. Our shared goal is to create a
more nimble process, with more flexible
licensing, and more open governance that
is not dependent on a single vendor. We
believe this will encourage more
participation and innovation. We see
general support for this new direction
from across the community.
This new direction implies many
changes, starting with a change in the
technology development process. The Java
EE process, or to be more specific, the
JCP process that was used for Java EE
development, is a highly structured
process that grants specification leads
significant influence over how
technologies are specified and
implemented. The EE4J process will be
different. It will be more open. Single
vendors including Oracle will continue to
contribute, but will no longer have the
same level of influence over how new EE4J
technologies evolve. We believe there is
consensus that this is a positive step for
the community.
This new development process
drives choices around use of the Java EE
name, and use of the javax.* package names
for new technologies. The Java EE and
javax.* names leverage the Java trademark,
and indicate that the source of these
technologies is Oracle and community
processes managed by Oracle. As a critical
identifier of the source of products to
our users, we must continue to reserve use
of such names using the Java trademark to
serving that fundamental source
identifying function. This will help us
to maintain the Java trademark, which is
in Oracle’s interest and in the
community’s interest. We recognize there
are likely to be requirements to create
new versions of existing Java EE
specifications that were already created
using the existing JCP process. We
believe we can work out an approach to
allow use of javax.* names for extensions
to these existing specifications in order
to accommodate these requirements.
However, if we adopt a new process for new
EE4J technologies, as is desired by the
community, we believe we must require that
a new namespace be used for the new EE4J
technologies that are developed using that
process, and a new brand (other than Java
EE) that includes these new technologies.
There is a tradeoff here, and we believe
that the net benefit of the new process
warrants the adoption of a new namespace
for new EE4J technologies, and a new
brand.
We will work with the EE4J
community to mitigate continuity concerns
that accompany this change. We are
making it very clear that EE4J will be an
evolution of existing Java EE 8
technologies:
• We are contributing our
existing GlassFish Java EE 8 Reference
Implementation sources to EE4J.
• We will contribute our
existing TCKs.
• We are intending to allow
certain uses of existing javax packages as
those packages evolve for compatibility.
• We are intending to allow
use of existing specification names for
component specifications.
• We are building an initial
EE4J implementation that is intended to be
both Java EE 8 and “EE4J” compatible.
• We will work with the EE4J
community to promote the new brand.
These are positive steps we can
take.
We support the efforts of the
EE4J Project Management Committee to make
branding recommendations to the Eclipse
Foundation. We encourage the community to
support the effort as well, and extend
thanks to all for the continued interest
in Java EE and EE4J technologies. And we
hope to deliver soon more new projects
with GlassFish sources contributed to
EE4J!
Thanks
Will
_______________________________________________
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
---
Mark Little
JBoss, by Red Hat
Registered Address: Red Hat
Ltd, 6700 Cork Airport Business Park,
Kinsale Road, Co. Cork.
Registered in the Companies
Registration Office, Parnell House, 14
Parnell Square, Dublin 1, Ireland,
No.304873
Directors:Michael Cunningham
(USA), Vicky Wiseman (USA), Michael
O'Neill, Keith Phelan, Matt Parson (USA)
_______________________________________________
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
---
Mark Little
JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork
Airport Business Park, Kinsale Road, Co. Cork.
Registered
in the Companies Registration Office, Parnell House,
14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael
Cunningham (USA), Vicky Wiseman (USA), Michael
O'Neill, Keith Phelan, Matt Parson (USA)
_______________________________________________
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
|