Jakarta EE 9.1 Release Contents and Status

As soon as Jakarta™ EE 9 was released, the community shifted its focus to Jakarta EE 9.1 and support for Java™ SE 11. During development of Jakarta EE 9, it became clear that supporting Java SE 8 and Java SE 11 was not feasible in the desired timeframe. In June 2020, it was decided that support for Java SE 11 would be pushed to a near-term Jakarta EE 9.1 release.

Here’s a look at what is, and is not, included in the Jakarta EE 9.1 release, along with some thoughts on the current status of the release.

Community Discussions Started the Process

The first order of business was to define the Jakarta EE 9.1 Release Plan. There were many thoughts and ideas about what should, and should not, be included in the release. As was the case with Jakarta EE 9, community members were not shy about sharing their opinions. We welcomed these ideas and discussions!

A generic Google Doc was created to capture the ideas provided through discussions, emails, tweets, surveys, and mailing lists. Topics included questions such as:

  • Should this release be a version 9.1 or a version 10?
  • If we support Java SE 11, does that mean we should also increase the minimum Java SE version — from 8 to 11?
  • What should we do about Common Object Request Broker Architecture (CORBA) and Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP) requirements?
  • Should we allow component specification updates?
  • Should we support Java Platform Module System (JPMS) modules?

These discussions eventually led to the belief that if we truly wanted a near-term release, we would have to limit our expectations and wish list. So, we went back to our original plan of supporting Java SE 11 as the sole requirement.

After another round of discussions with the community using a simplified Google Doc, we eventually ended up with the Jakarta EE 9.1 Release Plan.

Jakarta EE 9.1 Release Highlights

The requirements for Jakarta EE 9.1 can be stated as:

  • Support for the Java SE 11 runtime.
  • Jakarta EE Platform and Jakarta EE Web Profile will be the only specifications affected.
    • Specification documents, Technology Compatibility Kits (TCKs), and compatible implementations for the platform and web profile will be the only deliverables.
    • No other Jakarta EE component specifications will be included in Jakarta EE 9.1.
  • The top-level convenience jars for the platform and web profile will be reproduced at the 9.1 version, but the API content will be the same as Jakarta EE 9.

There’s a Lot of Testing to Be Done

As with most projects this size, the majority of the effort is spent on testing. In this particular case, it’s testing the compatible implementation — Eclipse Glassfish — with the updated Jakarta EE 9.1 TCK. Our original goal was to deliver Jakarta EE 9.1 by the end of March 2021. However, our test effort assessment indicates we will have to move the delivery date into the second quarter.

Although we are still experiencing a couple thousand failures with the TCK (remember the Platform TCK includes close to 50,000 tests), the good news is that very few of these failures are resulting in updates to Glassfish. Almost all of the necessary changes are contained in the TCK itself. They include scripting updates due to Java SE 11, demarcation of some optional aspects of Java and Jakarta EE such as CORBA and RMI-IIOP, and API signature tests required for Java SE 11.

Some additional good news is coming from the Open Liberty compatibility testing effort. Early testing against the Jakarta EE 9.1 TCK is showing a 99.9 percent success rate with Java SE 11. And this is occurring without any updates to the Open Liberty codebase used for certifying Jakarta EE 9. We’re expecting Glassfish to be rounding this corner very soon.

We Need Community Involvement

We’re always looking for additional community involvement. As I mentioned earlier, we received some excellent input and feedback when defining the Jakarta EE 9.1 release. Now that we’re nearing the homestretch, additional community participation in the testing and triage of failures is more than welcome.

Many of the problems encountered with the TCK effort are first logged as issues in the TCK repository. As more debugging occurs, other issues may be logged against Glassfish or the individual component implementations. Please take a few minutes to review the issues and see if you can help resolve them.

Jakarta EE would not exist without the continued support from the extended community. We appreciate everything you do to support this project!

About the Author

Kevin Sutter

Kevin Sutter

Kevin Sutter is co-lead of the Jakarta EE Platform project, as well as a member of the Eclipse EE4J Project Management Committee (PMC). Kevin also helps guide the overall Jakarta EE mission by participating on the Jakarta EE Steering and Specification Committees. Kevin's interest in the Enterprise Java programming models also extends into the MicroProfile arena, where he participates in the working group as well as co-lead for the MicroProfile project.