[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-community] Feedback to Joint Community Open Letter on Java EE Naming and Packaging
|
Hi,
First I'd like to thank you for this sincere explanation that leaves behind the legal reasons that used to be told.
That said, I can't agree with the observations.
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.
The community has received well the idea of a more open and fast process. But that can be achieved also by reforming the JCP. The community has not been asked how to achieve that more open and faster process.
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.
Agreed.
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.
Again, you are taking for granted the community prefers a new process that replaces the JCP over the continuation of the Java EE brand. Some public polls show different results, although they were all run from a subjective part of the community.
I can understand Oracle doesn't want to give away the javax.* package without a way to control the quality of the code published under it. But that can be easily solved by granting access only to existig packages and the javax.enterprise.* package. New JCP JSRs should not be allowed to use that subpackage in order to avoid collisions.
Users will be warned that code under that package is not under Oracle's control.
For me this is not only a thing of Java EE. It affects the whole Java ecosystem. Servlets are an official Java API and that's why we hsve so many implementations and libraries based on them. I doubt it would have been that way if they were originally created by a non official group.
With no JSON-B what would differenciate "EE4J Json binding" from Jackson or Gson? It would be just another library in the market, vanishing the idea of the "standard".
I don't believe this is what the community wants, but I'll be happy to accept my error if an independent poll is made asking what people prefer:
- A new more open and faster process, totally leaving the JCP, with the package and branding tradeoff, or
- A new more open and faster process, that then fills JSRs to the JCP (like OpenJDK or Microprofile Config), retaining the freedom to use the packages (I accept to lose the Java EE name here since the final product would be delivered by Eclipse).
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