EE4J will not inherit the Java EE name
© Shutterstock / vladwel
Oracle’s Will Lyons has responded to the Java EE Guardians’ open letter asking the company to allow the use of “Java EE” and “javax” packages for EE4J. Although Oracle will not allow the new platform to retain the Java EE name, they seem to have agreed to one of the requests.
EE4J will not inherit the Java EE name. Earlier this month, the Java EE Guardians published an open letter to Oracle asking them to allow the use of “Java EE” and “javax” packages for EE4J.
They offered six reasons as to why Oracle should allow the new platform to retain the Java EE name and the “javax” packages:
- Java EE remains a strong brand with developers. In industry survey after survey, developers make it clear they value Java EE.
- While no name is perfect, Java EE is a very suitable name for the platform. This has become especially apparent as the community has struggled repeatedly to come up with a sensible new name.
- The renaming of the platform from J2EE to Java EE causes continued market confusion even over a decade after the renaming. A further renaming of the platform will likely only add to the confusion. This includes the existence of pervasive resources referring to the Java EE name and javax packages. It will be unclear for a long time how these resources relate to a rebranded platform.
- Java EE should be and is seen as an integral part of the overall official Java open standard platform. This distinction is important and uniquely valuable to users, contributors, implementors and supporters of Java EE.
Any new name that does not prominently feature Java will diminish this value. The problem applies even more so to a packaging scheme other than “javax”.
- A new platform in which a significant portion of APIs belong in the “javax” package while another significant portion of APIs belong in another package is confusing and inelegant.
- Stability, backwards-compatibility and continuity are key characteristics Java EE adopters have valued for a long time. A forced rebranding can be perceived to be undermining these valuable characteristics.
Oracle’s answer arrived two weeks after the open letter was released.
In a message to the EE4J community mailing list, Will Lyons, Senior Director of WebLogic Server Product Management at Oracle explained why they will not allow the new platform to retain the Java EE name:
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.
It’s not all bad news
The battle for the Java EE name may be lost but this cloud has a silver lining. Will also wrote that the company acknowledges “there are likely to be requirements to create new versions of existing Java EE specifications that were already created using the existing JCP process.”
Therefore, they believe they 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.
Will also reminded the community that “Oracle has previously communicated that it intends to work with the EE4J community to:
- Define a branding strategy for the platform, including a new name for Java EE to be determined.
- 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.
- Use a different namespace naming convention, i.e. different from javax.*, for net new APIs/technologies.
He insisted that “EE4J will be an evolution of existing Java EE 8 technologies”:
- Oracle is contributing their existing GlassFish Java EE 8 Reference Implementation sources to EE4J
- Oracle will contribute their existing TCKs
- Oracle intends to allow certain uses of existing javax packages as those packages evolve for compatibility
- Oracle intends to allow use of existing specification names for component specifications.
- Oracle is building an initial EE4J implementation that is intended to be both Java EE 8 and EE4J compatible
- Oracle will work with the EE4J community to promote the new brand.
Read more about EE4J and why they are not using the Java EE name here.