BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Eclipse and Oracle Unable to Agree on Terms for javax Package Namespace and Trademarks

Eclipse and Oracle Unable to Agree on Terms for javax Package Namespace and Trademarks

This item in japanese

Lire ce contenu en français

Following many months of negotiations, the Eclipse Foundation and Oracle have been unable to agree on the terms of an agreement for the Eclipse Foundation community to modify the javax package namespace or to use the Java trademarks currently used in Java EE specifications. As a result, all future updates and improvements to the framework made under the auspices of Jakarta EE will go into a different package name and require a migration of application and library code.

Mike Milinkovich, executive director of the Eclipse Foundation, explained the end of negotiations for use of the javax.* package in an Eclipse Foundation blog post, "Update on Jakarta EE Rights to Java Trademarks." The post indicates the agreed-upon licensing rights for the historical package and represents a clear line for future implementations of Jakarta EE as its specification and Test Compatibility Kit evolve. "The implications of this are as follows", Milinkovich wrote:

  1. The javax package namespace may be used within Jakarta EE specifications but may be used "as is" only.  No modification to the javax package namespace is permitted within Jakarta EE component specifications. Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.

  2. Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.

  3. Specification names must be changed from a "Java EE" naming convention to a "Jakarta EE" naming convention.  This includes acronyms such as EJB, JPA or JAX-RS.

The change in package-name removes any ambiguity of ownership, that Java EE 8 and below were developed under the stewardship of Sun and Oracle, and Jakarta EE 8 and above are guided by the Eclipse Foundation. This change will impact every API in EE, as they all begin with javax. The change will likely trickle down into many non-EE web applications, including Spring web applications, as EE hosts the Java Servlet API, Java Mail API, and other critical components.

Mark Little, JBoss technical lead for Red Hat, provided a personal and technical analysis on the significant effort needed for this refactoring.

On a Twitter thread, Milinkovich points out that these negotiations were extremely complex, and also notes that Oracle has made many substantial donations:

Oracle contributed millions of lines of code in the reference implementations for Java EE, including GlassFish, Jersey, Grizzly, etc.  Oracle contributed the Java EE TCK. This was a huge step for them, as it was highly confidential and proprietary until then. This was a very large asset, with millions of dollars in Java EE licensing revenue attached to it. Oracle is licensing their copyrights in all of the Java EE specifications. This includes all of the past work that happened at Sun and BEA, so it is a very large percentage of the overall content of the specifications.

The change in package name will require developers to port their applications and libraries to use the new namespace. This introduces  a compatibility issue where existing applications must actively be migrated or they may encounter a forward-compatibility risk with the newer Jakarta EE. Integrated Developer Environments, such as IntelliJ IDEA, Apache NetBeans and Eclipse, can help to automate this refactoring. ByteBuddy author Rafael Winterhalter also noted on Twitter how powerful instrumentation agents can dynamically change package information. Mark Struberg, JSR-382 Spec Lead, has described some of the other options available in more detail, whilst noting "All those options have some drawback and I’m still not sure myself what would be the best solution."

This migration is a change from Java SE and Java EE’s long history of compatibility. "Almost two decades of software broken for no good reason. Absolutely stunning," laments Josh Long, Spring Developer Advocate for Pivotal. Long continues, "Bet on the Java Community Process (JCP) vendor standards they said. Trust in the JCP they said."

The JCP is a representation of elected and expert community members who evolve Java SE (JSR-386) and Java EE (JSR-000366) but does not hold any sway over the legal trademark for Java as it relates to computer programs. The trademark applies to the JCP itself, which is permitted to use the word in its name.

The applicability of the Java Community Process for EE has been under industry evaluation for several years leading up to this event. In 2016, Oracle executives Anil Gaur and Thomas Kurian shared a strategy for Java EE with the JCP. Oracle then donated Java EE to the Eclipse Foundation in 2017. One year after, Oracle said that it "does not recommend or support use of the JCP process for any future Java EE 8 functional enhancements." This process is still used for Java SE, guided by Heather Vancura.

David Blevins, CEO at Tomitribe, has indicated how developers and architects can participate in the transition of Jakarta EE to the jakarta namespace discussion that will conclude on Sunday, June 9, 2019. Those interested in participating can also consult the Jakarta EE Specification Process for their successor of the JCP, or join a new mailing list, Jakarta EE Platform Dev.

Rate this Article

Adoption
Style

BT