The goal of the Jakarta EE 9 release is to deliver a set of specifications functionally similar to Jakarta EE 8 but in the new Jakarta EE 9 namespace jakarta.*.
In addition, the Jakarta EE 9 release removes specifications from Jakarta EE 8 that were old, optional, or deprecated in order to reduce the surface area of the APIs to ensure that it is easier for new vendors to enter the ecosystem – as well as reduce the burden on implementation, migration, and maintenance of these old APIs.
Predominantly, the project team sees Jakarta EE 9 as a tooling release:
jakarta.* namespace.The scope of the Jakarta EE 9 release takes into account the guidance resolution passed by the Jakarta EE Working Group Steering committee shown below:
RESOLVED, the Jakarta EE Steering Committee requests that the Jakarta EE Platform Project leadership deliver a Jakarta EE 9 Delivery Plan to the Steering Committee no later than December 9, 2019, for the Steering Committee to consider adopting as the roadmap for Jakarta EE 9, and that the Jakarta EE 9 Delivery Plan accommodates the following constraints:
- implements the big bang
- Includes an explicit means to identify and enable specifications that are unnecessary or unwanted to be deprecated or removed
- Moves all remaining specification APIs to the Jakarta namespace
- States that no new specifications are to be added, apart from specifications pruned from Java SE 8 where appropriate, unless those specifications clearly will not impact the target delivery date
To be included in the Jakarta EE 9 release a specification MUST move their API package names from the top level javax package to the top level jakarta package. Other changes SHOULD NOT be made to the APIs defined in the specification apart from changes required to support the complete removal of specifications that have been pruned from this release. Methods SHOULD be removed and schema documents updated when they refer to APIs pruned from Jakarta EE 9. Any exceptions to this process will require individual Component Plan Reviews.
Individual specifications included within the scope of the Jakarta EE 9 Full Profile or Web Profile SHOULD convert the specification documents received by the Eclipse Foundation to the Jakarta namespace and refer to other Jakarta specifications and release these specification documents as part of the Jakarta EE 9 release.
Jakarta EE 9 WILL NOT impose any backward compatibility requirements for compatible implementations to support the Jakarta EE 8 release. This is aligned with our goal of enabling new implementations to enter the ecosystem. However, we strongly believe that many products and tools will provide backwards compatibility and migration solutions for enabling older applications to run on Jakarta EE 9.
For inclusion in Jakarta EE 9, specification’s APIs MUST be compiled at the Java SE 8 source level. Compatible Implementations of the Jakarta EE 9 Platform and Web Profile MUST certify compatibility on Java SE 8. Compatible Implementations MAY additionally certify and support later versions of the Java SE runtime.
As a move to the Jakarta EE namespace is a breaking change, all specifications included in the Jakarta EE 9 release MUST release a new major version of the specification document, APIs, and other artifacts. For example, semantic versioning at the specification level (ie. JPA 2.x -> 3.0), maven artifact level and semantic versioning at the Package level (OSGI) if appropriate for the specification (ie. jakarta.persistence at 3.0.0)
The following details the specifications included within the Full Profile of Jakarta EE 9.
List of existing specifications in Jakarta EE 9:
The following specifications previously part of Java SE 8 will be added to Jakarta EE 9 either as required or optional specifications as indicated and MUST be moved to the jakarta namespace.
Specifications marked optional in Jakarta EE 9 in addition to those added above and marked Optional above are:
List of specifications pruned in Jakarta EE 9:
The Jakarta EE 9 platform project is proposing that this release plan covers all specifications targeted for Jakarta EE 9. As stated in the scope, specifications will not be making functionality changes for inclusion in this release therefore individual specification release plans would be unnecessary ceremony. However, we are proposing that final Release Reviews are carried out individually for each specification to ensure artifacts are present.
We are proposing to deliver Jakarta EE 9 in a set of waves similar to those delivered in the Jakarta EE 8 release. These waves are somewhat related to the dependency tree of specifications. We aim to deliver specifications with a low number of dependencies first followed by other specifications.
The following specifications can be delivered independently of other apis.
The specifications included in Wave 1 are:
The specifications included in Wave 2 are:
The specifications included in Wave 3 are:
The specifications included in Wave 4 are:
The specifications included in Wave 5 are:
The specifications included in Wave 6 are:
The specifications included in Wave 7 are:
Jakarta EE specification projects MUST deliver milestone and RC builds to Maven Central with the namespace change as soon as possible to enable dependent projects to proceed with their required namespace change.
Jakarta EE specification projects COULD make full standalone releases of their specifications along with all finalized artifacts after following the JESP in advance of the full Jakarta EE 9 Platform releases.
Plan progress will be tracked in a GitHub project board at the Eclipse EE4J organization level. Milestones for each specification will be tracked across the project board columns.
It is the intention of the project team to deliver one or more release candidates of both the Full Profile and the Web Profile after the conclusion of Wave 7. The Profile Release candidates will include:
The purpose of the release candidate is to enable tools and users to try out the new APIs and discover any problems and inconsistencies prior to full release. We aim to leave a period of two months between the first release candidate and the final release to gather feedback and correct any minor problems prior to final release. Once the release candidate has been validated and any issues ironed out, the full release will proceed with all deliverables required for submission to the specification committee for approval.
The project team believe this timeline is aggressive and these are early estimate dates which will be reviewed and adjusted at each release review.
Update: These were the original proposed progress review dates at the time of the finalized Release Plan (Dec 2019). The overall schedule for Jakarta EE 9 will now be maintained on this separate page.
The JESP requires us to have a Compatible Implementation of the Full Profile and Web Profile available before the Platform Project can deliver a final specification. At this stage, it is assumed that this implementation will be Eclipse GlassFish. However, the Platform project has no control over the release dates of Eclipse GlassFish. The platform project will maintain close coordination with the Eclipse GlassFish project for the duration of the Jakarta EE 9 release development.
Additional clarifications for this Release Plan can be found in the Jakarta EE 9 Release Plan FAQ.