A deep dive into the Jakarta EE 9 Release Plan

The new year has begun, the holidays are behind us and, for most people, the daily routine has started again. And so it is for the Jakarta EE community – after the Christmas break in the last few weeks, work is now beginning again on the big goal for 2020, namely the release of Jakarta EE 9.

The Big Bang

As has been recently reported, Oracle was the first party to start formulating its own plans and ideas for Jakarta EE 9 at the end of last year and to put them up for discussion. However, since Oracle no longer has a special position with regard to the planning of Jakarta EE, these ideas primarily served as a basis for discussion of the next concrete steps.

The Jakarta EE Platform Project is responsible for the Jakarta EE 9 Release Plan. As the name suggests, this project is responsible for the platform specification, which in turn consists largely of the well-known individual specifications. For the Release Plan, the platform project has only received a few specifications from the Jakarta EE Steering Committee.

In early December 2019, the Steering Committee decided that Jakarta EE 9 should use the big bang approach for the migration from javax to the new jakarta namespace. It also decided that the migration of package names should become the central goal of Jakarta EE 9 and that there will be no new functionality. The only exception to this are a few specifications which have been removed from the JDK in Java SE 9 and are therefore inevitably needed. More about this later.

Based on Oracle’s first draft and the community’s feedback from the last weeks, the Jakarta EE Platform Project has developed the Release Plan and published it on the website. Currently the plan is being voted on, and although the vote is still ongoing, it is already becoming apparent that there is a clear majority for the current version. It can therefore be assumed that the plan will be approved in the course of this week. Reason enough to take a closer look.

Jakarta EE 9 Release Plan

As already specified by the Jakarta EE Steering Committee, the planning document first describes that namespace migration is the main goal for Jakarta EE 9. All specifications contained in Jakarta EE 9 must therefore migrate from the javax package to the new jakarta package. Beyond that there should be no changes to the specifications, which means that there will most likely not be any new functionality. However, the document also mentions that exceptions are possible, but require explicit consent. It is, however, unlikely that any specification will want to make use of this possibility.

Since the change in package names is a very serious change in terms of compatibility with previous versions, all specifications must get a new major release. Jakarta EE 9 will therefore contain Jakarta Servlet 5.0, Jakarta Persistence 3.0 and Jakarta Server Faces 3.0 to name but a few examples. One can certainly argue about the sense of a forced jump to the next major version, especially because it is only partially a “breaking change”. Although the package name changes, which in itself is a compatibility break, the specifications do not change in any other way, so the migration of the own source code can be done with a simple “search & replace” in many cases.

Documentation

In addition, it is recommended that the specification documents be adapted with respect to the new namespace. Unfortunately, this will not be possible for all documents, because not all projects have access to the documents. This is due to the fact that currently not all legal requirements have been met to allow further development of the specification documents under the umbrella of the Eclipse Foundation.

The reason for this is that all authors who have contributed to the documents in the past must explicitly grant permission for everything to run legally in an orderly fashion. Since some of the documents are more than 10 years old, this task is unfortunately not too easy to fulfill. This means that there is still a danger that the documents might not be released at all for certain specifications and would therefore have to be rewritten. We’re keeping our fingers crossed that the Eclipse Foundation will soon have good news in this regard.

In Oracle’s first draft of the Jakarta EE 9 plan, it was anticipated that downward compatibility to the old javax namespace would not be required by the platform. This should make it easier for new application server manufacturers to get started. Existing application servers will most likely offer some kind of backward compatibility of their own, allowing the operation of old Java EE applications to accommodate their own customers.

Java SE

Another point previously mentioned concerns the requirement for the Java SE version. Both Java EE 8 and Jakarta EE 8 require Java SE 8. Although Java SE 8 is still very common today, a new LTS version of Java SE, Java SE 11, has been available for some time. Oracle therefore proposed in the first draft of the plan to increase the minimum requirement to Java SE 11.

In the Release Plan, however, it has been implemented differently – the requirement now is that all specifications must be compiled with source level 8, but the application servers must certify their compatibility on the basis of Java SE 11. In practice, this variant should be sufficient to fulfill the wish of many developers: Jakarta EE 9 applications will be able to be developed with Java SE 11, even if the Jakarta EE API itself only uses Java SE 8.

SEE ALSO: Jakarta EE 8: A critical examination of the first Java EE successor

Specifications

The only question that remains is which specifications will become part of Jakarta EE 9 in the first place. Oracle proposed in their first draft of the plan to take the opportunity to remove some of the obsolete parts of the platform. The idea behind this is certainly to keep the effort for the namespace migration as small as possible. After all, why invest time and effort in specifications that have no relevance anymore anyway and have already been marked as “deprecated”?

The list of candidates for deprecation has been discussed intensively over the last weeks. In the end, however, the list turned out to be smaller than originally proposed by Oracle. This is mainly due to the fact that some vendors were not quite comfortable with the idea of removing specifications that are still actively used by their own customers. Although Oracle initially made it clear that products could of course continue to support the relevant technologies even if the platform no longer required them, this does not seem to be the case in practice. It is now clear that the following specifications will not be part of Jakarta EE 9:

• Jakarta XML Registries
• Jakarta XML RPC
• Jakarta Deployment
• Jakarta Management
• Support for Distributed Interoperability in the EJB 3.2 Core Specification

Considering that originally even the support of SOAP web services was discussed as a candidate for removal, this relatively small list is probably easy to handle. In addition, two other specifications are classified as “optional”:

• Jakarta Enterprise Beans 2.x API group
• Jakarta Enterprise Web Services, JSR 109

However, as indicated above, some new specifications will also be included in Jakarta EE 9. These are all technologies that were previously part of Java SE, but are no longer included in newer versions. Since Jakarta EE 9 now also targets Java SE 11, which lacks these APIs, a solution had to be found here. Specifically, the following specifications are involved:

• Jakarta Activation
• Jakarta XML Binding
• Jakarta XML Web Services
• Jakarta Web Services Metadata
• Jakarta SOAP with Attachments

With the exception of the first two, one rightly wonders why they were ever part of Java SE in the first place. Especially the topic “web services”, which actually falls into the enterprise category and probably should have been part of Java EE from the beginning. Originally it was discussed whether some of the five specifications should not even remain in the javax namespace, but in the end it was agreed to stay true to the “big bang” strategy and thus move all of them into the jakarta namespace.

Schedule

Finally we come to one of the most exciting questions. What exactly does the schedule look like? This aspect is also discussed in detail in the release plan. First of all, it has been decided that the specifications will be released in eight phases. This is mainly due to the dependencies between them; Jakarta Server Faces, for example, depends on Jakarta Expression Language, which of course means that it must be published in advance. The first phases are therefore more likely to include core specifications such as Jakarta Servlet, Jakarta Interceptors and Jakarta Expression Language, while the platform specification itself is in the final phases. The document explicitly states that milestones and release candidates are desired so that the specifications from higher phases can update their dependencies as quickly as possible.

SEE ALSO: Red Hat & IBM stand by Google in Supreme Court case against Oracle

With regard to the concrete time schedule, the document is as follows: In mid-February, i.e. in one month’s time, all specifications should provide first versions of the APIs that have already been converted to the jakarta namespace. By mid-March, the necessary adaptations to the Jakarta EE TCK should be implemented. From then on, the implementation projects would be able to start with the necessary adjustments due to the new package names.

A first Release Candidate for the platform specification is then planned by the beginning of May. In mid-June, the final round of voting on the release will begin; this is required by the Jakarta EE Specification Process. Thus, the final release can be expected in July. This schedule is even more ambitious than Oracle’s original plan, which was to aim for a release in September 2020.

Closing thoughts

Overall, the release plan makes a solid impression. Even though some issues were discussed very controversially before, a framework for Jakarta EE 9 has been agreed upon and everyone is more or less satisfied with it. Of course it is a bit disappointing that Jakarta EE 9 does not really bring any technical innovations but is completely focused on the topic of new package names. Nevertheless, Jakarta EE 9 is of course a very important release that frees the Jakarta EE community from legacy and legal restrictions.

The post A deep dive into the Jakarta EE 9 Release Plan appeared first on JAXenter.