Next up
Specifications Overview
Continuing in
Introducing Jakarta EE Fundamentals
This is a preview of subscription content
Your browser needs to be JavaScript capable to view this video
Try reloading this page, or reviewing your browser settings
This video segment is about the Jakarta EE Specifications Process.
Keywords
- Jakarta EE
- JCP
- Java EE
- The Eclipse Foundation
- EFSP
About this video
- Author(s)
- Tarun Telang
- First online
- 28 July 2021
- DOI
- https://doi.org/10.1007/978-1-4842-7339-5_5
- Online ISBN
- 978-1-4842-7339-5
- Publisher
- Apress
- Copyright information
- © Tarun Telang 2021
Video Transcript
In this section, let us look into the Jakarta EE Specifications Process. I’ll also provide you a high-level overview of some of the important Jakarta EE platform and web profile components. Jakarta EE specifications defines APIs, its behaviors, and their interactions.
It is intended to enable the development and verification of compatible implementations. Java Community Process is now replaced by Eclipse Foundation Specification Process– EFSP– which is managed under Jakarta EE Working Group. EFSP is a more collaborative process, as everything is driven by consensus. EFSP follows Code First approach, as at least one implementation is required before a specification is finally released.
Also, many difficult to remember acronyms have been given away for the sake of simpler names. For example, JPA is now renamed to Jakarta Persistence. To start a new specification project, first a project proposal describing the project is created.
Generally, the idea is first socialized with the Specification Committee, with the goal to build the context and give some support. Then a pull request is submitted in the GitHub repository for this specification project. A Specification Committee is also informed through email, and the creation review serves to access the community’s response to the project proposal and verifies the availability of resources for the project.
Before any extensive development on a specifications project, a planned review of release plan describing various activities is required. Planned review also requires creating a pull request with the details, as for the appropriate template. Once a release plan is approved, the release cycle is started.
Progress reviews are normally not part of the flow. But they are used to extend the release cycle. It can be initiated by project team to communicate that the accomplishments of the project to the Specification Committee, if they are not yet ready for release. Or, a Specification Committee may ask further progress review.
A final version of a specification cannot be made generally available until a release review is successfully completed, after which a ratified final specification is released. The same process is repeated for each of these specification versions.