Introducing Jakarta EE Fundamentals

Specifications

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.