- Compatible Products
THIS IS A DRAFT
Please revisit to keep updated
|Q1 2023||Q2 2023||Q3 2023||Q4 2023||Q1 2024|
|All||TCK pass w/Security Manager Disabled|
|All||TCK pass on Java SE 21|
|Components||Individual Component Spec Ballots|
|Platform||Platform TCK pass on Java SE 21|
The goal of the Jakarta EE 11 release is to deliver a set of coordinated specifications across the spectrum of Jakarta EE technologies.
The Platform team sees Jakarta EE 11 as the collection of component Specifications. Some of these component Specifications are introducing breaking changes to their API, which will require an increase in the Major version of the respective Specification. Many other component Specifications are introducing updates which are binary compatible and, thus, will only require a Minor version update. Regardless of the scope of changes, all artifacts for the component and Platform Specifications will be affected – Specifications, APIs, TCKs, and Compatible Implementations.
Java SE 21 will become the minimum runtime supported by Jakarta EE compatible implementations.
If a component Specification is planning a Major or Minor version update for Jakarta EE 11, then the recommendation would be to recompile and distribute the specification’s APIs at lowest required of Java SE 17 and Java SE 21.
Note:A component specification may be required to recompile to a higher Java SE level than it actually use depending on the specifications it depends on.
Note: The Platform API uber jar files will all be compiled at the Java SE 21 source/target levels. This is consistent with past practices.
The TCKs will be compiled at the Java SE 21 level.
In Jakarta EE 9.1, the framework for performing API Signature tests was updated to make it easier to test Signatures across multiple Java levels. The framework and/or API tests may need to be tweaked as we continue to learn and experiment with future levels of Java.
How a Compatible Implementation supports the Java SE 21 runtime (or above) will be left as a vendor-defined solution.
Suggestions on support for JPMS modules were introduced in the Jakarta EE 9 Platform Specification. It is desired to firm up these suggestions into requirements. Several discussions via Issues, Mailing Lists, and the Platform call have resulted in these requirements for Jakarta EE 11.
module-info.classfollowing a specified set of conventions:
module-info.class(guidelines will be provided)
module-info.classfor EE 11
Each Specification project should own the TCK source and produce the TCK artifacts. This needs to be done in such a way that the artifacts can be run to validate implementations at the individual specification level, as well as integrated into platform level TCKs.
This is a run-at goal for Jakarta EE 11. We know that not all Specifications can establish their standalone TCKs in this timeframe. The Platform TCK can initiate this refactoring by breaking apart the TCK source into separate directories within the Platform TCK repository. This will help with the eventual move of these TCK directories into their respective component repositories.
As mentioned, many of the Component Specification projects have already declared their intent for either a Major or Minor version update for Jakarta EE 11. These projects have already submitted or completed their Plan Reviews for inclusion in Jakarta EE 11, and are driving towards a Q1 2024 release. These updates are outlined in the sections below.
The following details the specifications and APIs currently planned for the Jakarta EE 11 Platform and Web Profile.
List of specifications in Jakarta EE 11 Platform, Jakarta EE 11 Web Profile, and Jakarta EE Core Profile (updated specifications marked with asterisks).
TODO: add list of specifications
The Platform and Web Profile API uber jar files will be re-generated to correspond with the Jakarta EE 11 release designation.
These API uber jar files will be compiled and distributed at the Java 11 source/target levels.
Note: These uber jars will not be modularized, per the earlier discussion.
The Jakarta EE 11 Platform release plan covers the Platform and Web Profile specifications. As stated earlier, all component Specifications which plan a Major or Minor release will be creating their own separate release plans.
We are proposing to deliver Jakarta EE 11 in a set of waves similar to those delivered in the previous Jakarta EE releases. 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:
With the rather large Jakarta EE 11 release scope, at least one Release Candidate for Jakarta EE Platform and Web Profile will be produced. These Release Candidates will include:
Once the release candidates have been validated and any issues ironed out, the full Jakarta EE 11 release will proceed with all deliverables required for submission to the specification committee for approval.
The JESP requires us to have a Compatible Implementation of the Full Platform and Web Profile available before the Platform Project can deliver a final Specification. Discussions are occurring with the Specification Committee to allow for additional ratified compatible implementations (besides always relying on Eclipse Glassfish). The Platform project has no control over the release dates of any potential Compatible Implementations. The platform project will maintain close coordination with the various Compatible Implementations for the duration of the Jakarta EE 11 release cycle.
Additional clarifications for this Release Plan can be found in the Jakarta EE 11 Release Plan FAQ.