Joint Community Open Letter on Java EE Naming and Packaging

Oracle has promised to open up the ownership of Java EE by moving it to the Eclipse Foundation via the EE4J project. This is a tremendously positive move that will make a very important part of the overall Java platform truly open and agile.

The problem is that Oracle wants to restrict the use of the word “Java” and the use of the “javax” packages for EE4J due to corporate branding concerns. This is forcing a rename of Java EE and the use of another package for new Java EE technologies. We believe this desire is not aligned with the best interests of the community and the industry. This may indeed also be true of Oracle’s own business interests as Java EE is moved further in the direction of microservices, the cloud and serverless computing.

The clearest evidence that the current direction to rename and repackage Java EE is wrongheaded is community opinion. When asked, developers overwhelmingly support keeping the Java EE name and “javax” packages (#1, #2). These preferences are so strong they have remained unchanged for several months even despite current declared EE4J plans.

There are several sensible reasons these preferences make sense:

• 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.

All of these factors will likely stand in the way of the rapid success of a new platform with a new name and new package structure. Indeed these factors – particularly a perceived lack of continuity – may even negatively impact adoption of existing Java EE technologies.

On behalf of the community, the Java EE Guardians ask that Oracle and other EE4J stakeholders work together to allow the new platform to retain the Java EE name, the “javax.enterprise” package for new technologies and existing “javax” packages for existing technologies.

There are many ways these goals could be accomplished. The following are just a few obvious possibilities.

• Oracle can license the Java EE name to the Eclipse Foundation. The license can allow limited use of the “javax.enterprise” package for new technologies, limited use of the “javax” packages for existing technologies but still allow Oracle to retain control over the rest of the “javax” package for non-Java EE technologies. If needed Oracle can separately trademark the Java EE brand from the Java brand. Such an action is not without precedent. Sun Microsystems licenced the “JavaScript” trademark to Netscape. Allowing a limited license to the Eclipse Foundation would not diminish the Java brand at all. Indeed, similar to JavaScript, allowing for Java EE to be opened up will only enhance the Java brand, much like the C# brand being enhanced by Microsoft choosing to standardize it through the ISO/ECMA independent standards organizations.
• While naming is a very important concern, retaining the “javax/javax.enterprise” packages is even more important. One way this could be easily accomplished is still standardizing EE4J technologies though the JCP. The relationship between EE4J and the JCP could be very similar to the relationship between OpenJDK and the JCP. While most work can happen in EE4J, the JCP could be used as a passthrough standardization mechanism. The recent faster release cadence for Java SE through the JCP proves that agility is not the major concern in the JCP. The downside of the approach is that Oracle and other EE4J stakeholders would need to work together to resolve mutual concerns over the JCP.

The Java EE Guardians sincerely hope Oracle and EE4J stakeholders listen to and adequately address community concerns. It must be noted that even if the naming and packaging issues are not properly resolved, timely forward movement of the EE4J initiative is still in the best interests of the community.

The Java EE Guardians stand behind the EE4J initiative even despite the fact that failing to properly resolve the naming and packaging issues will pose significant challenges to an already daunting effort.

The Java EE Guardians are a joint community of many Java Champions, Java User Groups, Java User Group leaders, JCP experts, JCP members, open source committers, authors, bloggers, speakers and ordinary Java developers around the world.