As most of you are aware, Oracle has contributed the Java EE specification to the Eclipse Foundation. The enterprise Java community decided to rename the Java EE specification to Jakarta EE. Part of this huge transition to open source is changing the specification process. The famous Java Community Process (JCP) is going to be replaced by the Eclipse Foundation Specification Process (EFSP), which will be better suited for vendor neutrality, transparency, and all other attributes associated with open source. So what exactly is the difference?
To learn more about the new process, please refer to the EFSP v1.0, and Wayne Beaton’s article in this newsletter.
There are many differences between the Eclipse Foundation Specification Process (EFSP) and the Java Community Process (JCP), but let’s focus on my top 5!
Code First: While the JCP proposed to have a specification document created first, the EFSP will be firstly based on the hands-on experimenting and coding, as a way of proof that something is worthy of documenting in a specification. Once the code is in good shape, we can proceed with the creation of a specification document that will support the code and not the other way around.
Collaborative: The EFSP is defined and managed by the Jakarta EE Working Group members, which is governed as a vendor-neutral group and will be used by the wider Jakarta community for a specification creation and implementation. We ensure a level playing field for everyone in the Working Group to participate in the specification creation via collaboration. Collaboration of this type also ensures the sharing of knowledge and the growth of the developers participating in the process.
Documents and TCKs are open source: The key benefits of the EFSP are producing documents and open source TCKs. This means the following for the community: Transparency, Openness, Shared Burden, and Vendor Neutrality. You can refer to the open source TCK blog for more information. Opening the specification to the community and having them influence the technical direction as well as provide feedback enables a large pool of people to get involved, which ultimately results in better quality! Transparency, openness, and vendor neutrality were not part of the JCP.
Compatible Implementations: The JCP required that each specification version has a corresponding Reference Implementation. The EFSP will require at least one Compatible Implementation of a specification, however, we are welcoming and encouraging other implementations of the specification and are avoiding singling out or favoring particular implementations or a vendor. We are hoping this will further encourage adoption and involvement of the community.
Self-certification: For the certification process for the EFSP, we utilize a self-serve model, thus lowering the costs and effort involved in carrying out certifications. The Eclipse Foundation will provide all the necessary information and instructions for the certification and make them available for download. There is an explicit requirement for all test results to be made publicly available so that verification can be carried out.
Specification processes’ are, by nature, involved, detailed, and fairly complex. Care has been taken to ensure the overhead associated with engaging in the specification process is no more significant than it needs to be. But, as we further progress and learn, we will tweak the process based on these learnings.
We hope you’ll get involved!
This post was originally published in the January 2019 issue of the Eclipse Newsletter: 2019 in Focus.
For more information and articles check out the Eclipse Newsletter.
The post How is the Eclipse Foundation Specification Process (EFSP) different from the Java Community Process (JCP)? appeared first on JAXenter.
Source : JAXenter
