Read, review, contribute

The draft of Jakarta EE Specification Process is live!

JAXenter Editorial Team
Jakarta EE
© Shutterstock / Inspiring  

The time has come! The Eclipse Foundation has announced the draft of the Eclipse Foundation Specification Process and invites the community to read it, review it and give feedback.

The Eclipse Foundation published the draft of the Eclipse Foundation Specification Process and invites the community to contribute by reviewing it and giving feedback.

Here, we will have a quick overview of the most important points of this draft.

As stated in the first sentence of the draft this document “describes the Eclipse Foundation Specification Process (EFSP) for optional use by Eclipse Foundation Working Groups.” 

Before diving into all the important aspects of the specification process, the draft defines numerous terms in the context of the document.

Moving on to the main focus of the document, the processes concerning structure and organization as well as the Specification Process, that are examined include:

Specification Versions – Each Specification Version references specific versions of its constituent artifacts. These artifacts include the Specification Documents, zero or more other Specifications, one or more Compatible Implementations licensed under an Open Source License, and exactly one associated TCK for this Specification.

Committers – Specification Project Committers must be Members of the Eclipse Foundation. Committers may be Members by virtue of working for a member organization or may choose to complete the membership process independently.

Release Plans – A Release Plan lists themes and areas of focus, describes Milestones, and lists tentative dates for Reviews. The work defined by a Release Plan must be within the Scope of the Specification Project.

Specification Version Lifecycle – To produce a Specification Version, a Specification Project must engage in a formal Release Cycle under the supervision of the Project Management Committee (PMC) and the Specification Committee.

Reviews – Reviews are a formal process through which all major lifecycle events and changes to Specification Projects are announced and reviewed by the membership-at-large, and approved by the PMC, the Specification Committee, and the EMO.

Ratification – With the successful completion of a Release Review, including approval of the Specification Committee by a Super-majority vote, a Specification Version is Ratified and the associated artifacts can be promoted and distributed by the Specification Committee as a Final Specification.

For further details and for a chance to give your feedback, head over to the Eclipse Foundation Specification Process draft.

Confused about what’s going on with Jakarta EE? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java. 

Here are the interviews we have so far:

  • David Heffelfinger: “I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool”
  • Markus Eisele: “I strongly believe there is a lot to do to make Jakarta EE ready for the future”
  • Josh Juneau: “The platform needs to evolve more dynamically than it had done in the past”
  • Werner Keil“Jakarta EE should become more modular than it is right now”
  • Ondrej Mihalyi“MicroProfile is paving the way for better microservices support in the Jakarta EE ecosystem”
  • Reza Rahman“Modularity is key to faster release cycles”
  • Dmitry Kornilov“Jakarta EE APIs should be more cloud-friendly”
  • Arjan Tijms“Recognizing the importance of Kubernetes likely means a further reduction in the importance of running multiple applications on a single Jakarta EE server”
  • Richard Monson-Haefel“Jakarta EE 9 will begin the transition to a simpler, lighter, and more flexible platform”
  • Otávio Gonçalves de Santana“Jakarta EE tools should support Kubernetes”
  • Guillermo González de Agüero“MicroProfile saved Java EE & will have a key role in its cloud-native transformation”
  • Michael Hofmann“Combining Jakarta EE with MicroProfile could slow down the progress of MicroProfile”
  • Mark Struberg “JakartaEE should allow intermediate ‘bugfix releases’”
  • Scott M. Stark “MicroProfile’s purpose will still be useful even after Jakarta EE is fully functional”
  • Markus Karg“While Jakarta EE 8 does not add much functionality on top of Java EE 8, people should adopt it ASAP to provide feedback”
  • Rudy De Busscher“The MicroProfile specifications can fill the missing gaps of Jakarta EE if you want to use microservices today”
  • Sebastian Daschner“Jakarta EE should address some of Java EE’s past shortcomings”
  • Steve Millidge“MicroProfile has made excellent progress in experimenting with Microservice APIs built on a foundation of Jakarta EE APIs”
  • Christian Kaltepoth“User feedback is of central importance so that Jakarta EE can go in the right direction”
  • Thilo Frotscher“The platform must support cloud and container operations better”
  • Thorben Janssen“The integration of Kubernetes should be a priority for Jakarta EE”
  • Meet Mark: “If MicroProfile and Jakarta EE tried to merge now, both would suffer”



Inline Feedbacks
View all comments