Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Jakarta EE 9 Delivery Plan

The Jakarta EE 9 Delivery Plan

This item in japanese

Lire ce contenu en français

Anticipating a mid-2020 GA release, the Jakarta EE platform project team presented the formal Jakarta EE 9 delivery plan to the steering committee. It is expected that Jakarta EE 9 will be a stable tooling release from which: tooling vendors can support the new jakarta package namespace; development teams can test migration of their applications to the new namespace; and runtime vendors can test and deliver options and capabilities that support migration and backwards compatibility with Jakarta EE 8. Jakarta EE 9 may also be considered a foundation for innovation to drive new features in Jakarta EE 10 and beyond.

When Oracle chose the Eclipse Foundation as the new home for Java EE, Reza Rahman, principal program manager of Java on Azure at Microsoft, invited the Java community to participate in two surveys. The first survey, conducted in August 2017, asked if Java EE should be renamed. Two-thirds of respondents supported keeping the Java EE name. The second survey, conducted in November 2017, asked if Oracle should allow the Eclipse Foundation to maintain the Java trademark and javax package namespace. Three-quarters of respondents supported this initiative. In a joint community open letter to Oracle, Rahman summarized these results and enumerated several reasons to maintain the status quo, including: Java EE maintains a strong brand; renaming Java EE could cause marketing confusion; and Java EE should be valued as an open source platform.

Negotiations between the Eclipse Foundation and Oracle, settled in May 2019, on the Jakarta EE rights to Java trademarks determined that the Java trademarks are the exclusive property of Oracle, and that the Eclipse Foundation does not have the right to use them. As a result:

  • 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.
  • Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.
  • 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.

David Blevins, CEO at Tomitribe, offered two proposals, with pros and cons for each, as a solution to the javax to jakarta package namespace migration: the "big bang," migrate all at once; and "incremental," migrate as necessary over time. Responses to the proposals seemed to favor the "big bang" approach, but Blevins didn't stop there. A new namespace section within the Jakarta EE platform GitHub repository was created as an "informal wiki-like place where data can be collected about the various impacts of the javax to jakarta namespace change." Explaining his rationale for this effort:

One month of discussion will bring no fruit if we do not curate information as we go. People will stop contributing very quickly due to inability to digest two weeks of free flowing discussion.

Blevins' bytecode analysis yielded multiple documents that included Jakarta EE API dependencies, a mapping of javax to jakarta, and transitive changes on the Jakarta EE APIs.

Mike Milinkovich, executive director at the Eclipse Foundation, recently discussed moving forward with Jakarta EE9 and acknowledged the Java community effort in developing this release plan, writing:

A lot of time and energy went into its development. It has been exciting to watch the ... ummm passionate ... discussions evolve towards a pretty broad consensus on this approach. I would like to particularly recognize the contributions of Steve Millidge, Kevin Sutter, Bill Shannon, David Blevins, and Scott Stark for their tireless and occasionally thankless work in guiding this process.

Reflecting on 2019, Milinkovich also noted highlights that included: the success of the inaugural JakartaOne virtual conference; Jakarta EE having been one of the recipients of the Duke's Choice Award; and the publication of the second annual Jakarta EE developers survey.

As per the responsibilities of all the Jakarta EE committees, the Jakarta EE project platform team is responsible for: producing the roadmap and release plan; tracking the release timelines; ensuring at least one compatible implementation is available; and providing periodic updates to the Steering Committee and Specification Committee. This is required for every Jakarta EE release and follows the Jakarta EE Specification Process (JESP). Development of the release plan was open to input from the Java community through mailing lists and the weekly Jakarta EE platform teleconferences.

Steve Millidge, founder and CEO at Payara, discussed the rationale behind the decisions of the release plan, writing:

With the namespace change required from javax-jakarta it created a breaking change to backwards compatibility. The project took the opportunity to remove a number of old APIs, make some more optional (and therefore not required for a new application server) and to not require backwards compatibility with applications written in the old namespace. This means it is possible to deliver a new application server that is fully compatible with Jakarta EE 9 that only supports the Jakarta EE 9 APIs in the new namespace on JDK 11. For me, this is a huge win and gives us an opportunity to innovate with new Jakarta EE 9 runtimes, while still giving the option to support old applications on Jakarta EE 9 products.

Will Lyons, senior director, project management at Oracle, summarized his thoughts on the Jakarta EE 8 release with a focus on areas of improvement, writing:

The goal of the retrospective was to collect feedback on the Jakarta EE 8 delivery process that can be turned into action items to improve our delivery of subsequent releases, and enable as much of the community to participate as possible.

Areas of improvement included specification and release management, communications and organization. In response, the Jakarta EE steering committee will focus on improvements in all of these areas.

Jakarta EE 8, formally released in September 2019, was delivered as Java EE 8 using the javax package namespace. The primary goal of Jakarta EE 9 is to deliver specifications similar to Jakarta EE 8 with the jakarta package namespace implemented in the specification.


Rate this Article