WatersWorks

Blog archive

Oracle's Jakarta EE 9 Proposal: Pruned Specs and a Big Bang

The Eclipse Foundation announced the released the Eclipse Jakarta EE 8 specification just over two months ago and we’re already seeing the solidifying outlines of Jakarta EE 9 -- not especially fast by current release-cadence standards, but warp speed when you consider how enterprise Java had languished before the Foundation accepted the stewardship of the platform two years ago.

Oracle software architect and Eclipse committer Bill Shannon posted his company’s proposed plan for Jakarta EE 9 on October 1 on the jakartaee-platform-dev mailing list, sparking a great deal of discussion in the community. About a week later, he returned to the mailing list with a “recast plan” based on the feedback he received.

“Nothing here is final,” he wrote in that first post, “and we're open to discussion on all these items. Feedback is strongly encouraged. Counterproposals are welcomed. Our intent is to put a stake in the ground to start the planning for Jakarta EE 9.”

Shannon’s subsequent post included a bunch of changes, which suggests that Big O won’t be bigfooting the process. He received the most feedback, said, around the removal of SOAP support.

“I think we've adequately explained that products can continue to provide SOAP support based on the Jakarta versions of the corresponding specifications,” he wrote, “which will have no changes to their APIs and will continue to use the javax namespace.”

If platform project committers believe SOAP support must be included in version 9, he added, they should speak up now, but also keep in mind that including SOAP support “would have a significant impact on the amount of work to be done for Jakarta EE 9.”

Oracle’s modified plan would “prune” several specs from the version 9 release, including:

  • Jakarta XML Registries
  • Jakarta XML RPC
  • Jakarta Deployment
  • Jakarta Management
  • =
  • Jakarta Enterprise Bean entity beans
  • Jakarta Enterprise Bean interoperability
  • Jakarta Enterprise Bean 2.x and 1.x client view
  • Jakarta Enterprise Web Services

The plan would also not add some API’s corresponding to Java SE 8 APIs, including:

  • Jakarta XML Web Services
  • Jakarta SOAP Attachments
  • Jakarta Web Service Metadata
  • CORBA and RMI-IIOP

Two APIs corresponding to Java SE 8 APIs will be added to Jakarta EE 9:

  • Jakarta XML Binding
  • Jakarta Activation

Oracle favors the “big bang” approach to package naming -- switching everything from javax.* to jakarta.* all at once.

Some sort of backwards compatibility will be required, of course, to allow existing applications to work unchanged on Jakarta EE 9 products using the jakarta.* namespace, but Oracle is against defining that backwards compatibility in a Jakarta EE spec.

“We strongly encourage the creation of an open source project to produce backwards compatibility support that can be shared by multiple implementations of Jakarta EE 9,” Shannon wrote.

Although no additional profiles are being proposed for Jakarta EE 9, Oracle is apparently open to the idea of creating two additional profiles “to help additional vendors enter the Jakarta EE market.”

“We believe that the need of developers to ‘right-size’ their application deployment is best addressed by the use of Java platform modules, not profiles, defined by a future Jakarta EE release,” Shannon wrote.

Oracle also believes all Microprofile work should be done under the Eclipse Foundation Specification Process, should be considered additions to the Jakarta EE platform under that process, and should be deferred to a future Jakarta EE release. When and how Microprofile APIs should be added to the Jakarta EE platform is “an open issue.”

Big O is also backing what appears to be strong community support for the idea of splitting up the Jakarta EE TCK project, so that each specification project can manage its own TCK. But the company believes the work involved would be too much to include that change in this release.

“Possibly incremental progress can be made in the Jakarta EE 9 timeframe,” Shannon allowed. “It's essential that work in this area not make it more difficult to test a Jakarta EE 9 product.”

Oracle also wants to keep up the pace with a Jakarta EE 9 release12 months or less after the release of Jakarta EE 8.

Posted by John K. Waters on October 22, 2019