Jakarta EE 9, the second formal release since it's debut in 2018, is scheduled for a GA release on November 20, 2020. Originally scheduled for September 16, 2020 in conjunction with the second annual JakartaOne Livestream 2020 conference, delays made it necessary to push back the GA release date.
As specified in the Jakarta EE 9 release plan, developers can expect 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.
David Blevins, CEO at Tomitribe and Jakarta EE Steering Committee member, told InfoQ about the contributions of Kevin Sutter, Jakarta EE 9 release lead at IBM, regarding the Jakarta EE 9 release plan:
Kevin Sutter deserves a bit of spotlight for his work on the final plan that was approved. He was the guy who herded all the cats at the last mile. He got all the threads wrapped up, ran the open community votes, organized community calls all November and December and drafted the final plan all on the timeline requested by the Steering Committee.
The first milestone release of Jakarta EE 9, celebrated on June 23, 2020, included updates on the Jakarta EE Platform project (Platform and Web Profile 9.0.0-RC2 APIs), Jakarta EE TCK (Platform TCK 9.0.0-M1), Eclipse GlassFish 6.0-M1 and the Eclipse Transformer project. The event was attended by 155 developers representing approximately 20 countries.
The updated Jakarta EE specifications included in this new release have been incrementally passing TCK and voting ballot. For example, the Bean Validation 3.0 specification was the first one ready for Jakarta EE 9.
Kevin Sutter spoke to InfoQ about the upcoming release of Jakarta EE 9.
InfoQ: Please describe to our readers the certification and voting process for each Jakarta EE specification.
Kevin Sutter: The Specification certification and voting process ensures that our stakeholders (Specification Committee membership) have sufficiently reviewed and approved the artifacts associated with a Specification Version -- the Specification document itself, the associated API, the TCK (Test Compatibility Kit), and a CI (Compatible Implementation) - that properly implements and tests the Specification. Without this "blessed" related set of deliverables, the consumer would not have the confidence required to put this technology into production development or usage. This certification and voting process is probably the most important job of the Jakarta EE Specification Committee.
In a nutshell, each Specification Project (i.e., Persistence, Concurrency, Bean Validation, etc) needs to prepare their artifacts for this certification and voting process. This is done via PRs (Pull Requests) against the specifications repository. All of the necessary material is provided either via some defined markdown files (i.e.,
_index.md) or via the checklists, which are added to each of the PRs.The Specification Committee assigns a mentor from the Committee to ensure that all of the t's are crossed and i's are dotted for the final ballot. Once the mentor signs off on the PR (based on input from all sources), then the mentor can initiate a formal ballot on the Specification Version. This ballot is performed on our public Specification Committee mailing list. Besides the Specification Committee members, we also encourage the reviewing and approving of the material from the wider community. The ballot passes if we get a super majority of the membership indicating a +1 vote.
Almost all of the time, due to the due diligence of the mentor and the other reviewers, the ballots come through with a passing vote. But, there are documented exceptions where a vote may need to be rescinded and restarted after the issues are addressed.
InfoQ: What's on the horizon for Jakarta EE?
Sutter: First on the horizon is a Jakarta EE 9.1 release. Originally, Jakarta EE 9 was going to support compatibility with both Java SE 8 and Java SE 11. Due to some issues discovered while testing the Platform TCK and CI earlier this summer, Java SE 11 support had to be dropped. This was done to ensure that we still delivered Jakarta EE 9 this fall. Thus, Jakarta EE 9 will only support Java SE 8. As soon as Jakarta EE 9 is out the door, Jakarta EE 9.1 will be underway in order to support Java SE 11. This should be a relatively quick release. The items that need to be addressed are pretty well understood. It's a matter of codifying these assumptions and completing the implementation and testing. Then, we can start thinking about Jakarta EE 10.
First off, we are actively looking for someone to drive the Jakarta EE 10 release. Driving the Jakarta EE 9 release was a very rewarding experience. I learned a great deal about Jakarta EE as a Platform, as well as some of the challenges the individual technologies have faced. But it's time to bring in some new blood with fresh ideas to drive this next major release of Jakarta EE.
As far as specific items for Jakarta EE 10, I've been so heads down on Jakarta EE 9 that I really haven't looked out on the horizon much. I would like to see some new Specifications get introduced into the Jakarta EE family - maybe as part of the Platform, but maybe just as standalone Specifications.
We have two new Specification Projects that are just starting out - Jakarta MVC and Jakarta NoSQL. The MVC project started out with the JCP and has recently migrated over to Jakarta EE. They have a little bit of a head start since they were actively creating a Specification under the guidance of the JCP. It will be interesting to see whether they are far enough along to integrate with the Platform.
The NoSQL project has quite a bit of early implementation experience, which supports our mantra of "code first." The interesting aspect of this project is whether we can get sufficient community involvement to demonstrate interest across a spectrum of users. And, we can define how NoSQL does, or does not, interact with the existing Persistence (JPA) and JDBC technologies.
The other big elephant in the room is MicroProfile (another one of my pet projects). Now that the MicroProfile Working Group has been established, they will be creating Specifications following the Eclipse Foundation Specification Process (EFSP) just like Jakarta EE. This opens the door for more collaboration between these projects. In the past, Jakarta EE had an issue with specifying a dependency on a MicroProfile technology due to the lack of the EFSP usage. This should now all be resolved and I would expect more synergy between these two development efforts.
InfoQ: How may the Java community get involved in contributing to Jakarta EE?
Sutter: This is one area where we can continue to grow. During Jakarta EE 8, the main contributors were members of the Specification Committee. With Jakarta EE 9, we saw that sphere grew and more people were contributing to the Specification Projects and helping to prepare the PRs for ballot.
Now that we have this foundation of Jakarta EE 9, we need even more community involvement. My suggestion is to start off small. Find a project in which you have interest and ask how you can help out. Or, monitor their mailing list and/or issues and suggest changes and improvements. If you have skills that could help resolve an issue, offer up a PR to resolve it.
Almost every Project is looking for help with defining the next release (service or major). So, just jump in and try to help out. You'll find it much easier to contribute at the beginning of a new release when a specific plan is not yet solidified.
There are other ways to contribute as well. There are several repositories related to demonstrating Jakarta EE's capabilities. Or, maybe you like to write about technology. Blog posts about Jakarta EE are always welcome. We also have the "Adopt a Spec" program where JUGs can play a more active role with Specifications.
InfoQ: What else should our readers know about Jakarta EE 9?
Sutter: Jakarta EE 9 has truly been an open-source success. This year has brought in so many challenges. When we first came up with a release plan for Jakarta EE 9 in the first months of 2020, we really thought that June 2020 would be a doable release date. But, then the pandemic hit and all of our lives were turned upside down. Even if you were not directly affected by the virus, you knew somebody that did. Or, maybe your kids are now being home schooled for the first time. Or, maybe your company was affected by the economic downturn. Whatever the conditions, you were probably somehow affected by the virus. And, this had a worldwide effect.
Coupled with that, the work for Jakarta EE 9 was a bit more involved than originally envisioned. The ripple effect of changing
javaxtojakartawas more involved than expected. Hindsight is 20/20, but some items came to the surface after we started to peel thisjakartanamespace onion. And, the question of supporting Java SE 11 slightly complicated the schedule.But, we continued to work with the community to figure out what was doable. Eventually, we landed on the November 20th date and, so far, this is looking good!
JakartaOne Livestream 2020, now scheduled for December 8, 2020, will have a similar agenda to the inaugural JakartaOne Livestream 2019 conference that was held in conjunction with the formal release of Jakarta EE 8 in September 2019.
Editor's Note
Michael Redlich serves on the leadership council of the Jakarta EE Ambassadors and will serve on the program committee for the JakartaOne Livestream 2020 conference.