Q1 2025 | Q2 2025 | Q3 2025 | Q4 2025 | Q1 2026 | Q2 2026 | June/July 2026 | |
---|---|---|---|---|---|---|---|
Components | Plan Reviews | ||||||
Platform | Plan Review | ||||||
All | M1 release | ||||||
All | M2 release | ||||||
All | M3 release | ||||||
All | M4 release | ||||||
Components | Further refine implementations | ||||||
Core Profile | Core Profile ballot | ||||||
Web Profile | Web Profile ballot | ||||||
Platform | Platform ballot | ||||||
Platform | Release |
Java SE 21 will become the minimum runtime supported by compatible implementations of Jakarta EE.
--release
LevelFor the Jakarta EE Platform (Platform, Web and Core), the Java compiler --release
option is 21. For the component specs, the Jakarta EE Platform requires the Java compiler --release
option is at most 21, but component specifications can decide on a lower level.
The long-standing policy of considering specification API binaries, in Maven Central or anywhere else, as a non-normative convenience remains unchanged. The platform project is silent on this matter. However, because the platform project does mandate a specific JDK requirement for compatible implementations passing the component or platform TCK, if a component specification does publish an API binary, that binary is practically constrained to follow that mandate.” See TCK Source Level
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 12.
module-info.class
following a specified set of conventions:
jakarta.<specName>
(reference names.adoc)module-info.class
for EE 12
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.
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.
The Platform and Web Profile API uber jar files will be re-generated to correspond with the Jakarta EE 12 release designation.
These API uber jar files will be compiled and distributed at the Java 12 source/target levels.
Note: These uber jars will not be modularized, per the earlier discussion.
The Jakarta EE 12 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.
TBD
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 12 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 12 release cycle.
Additional clarifications for this Release Plan can be found in the Jakarta EE 12 Release Plan FAQ.