By now most of you are aware already that Oracle has contributed Java EE specification to open source, and into Eclipse Foundation. The Java enterprise 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 Eclipse Foundation Specification Process (EFSP), that will be better suited for vendor neutrality, transparency and all other attributes associated with open source. So what exactly is different?
There are many differences between Eclipse Foundation Specification Process (EFSP) and Java Community Process (JCP), but let’s focus on my top 5!
Code First: While JCP proposed to have a Specification document created first, EFSP will be based on hands-on experimenting and coding first, as a way to prove something is worthy of documenting in a specification.
Collaborative: EFSP is defined and managed by 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. Ensuring a level playing field for everyone in the WG to participate in Specification creation is done via collaboration.
Documents and TCKs are open source: The key benefits of EFSP are producing documents and TCKs that are open source. This means the following for the community: Transparency, Openness, Shared Burden and Vendor Neutrality. You can refer to this open source TCK blog for additional insights. Opening the Specification to the community and having them influence the technical direction and provide feedback enables a large pool of people to get involved, which ultimately results in better quality! Transparency, openness, vendor neutrality were not part of the JCP.
Compatible Implementations: The JCP required that each specification version have a corresponding Reference Implementation. EFSP will be requiring at least one Compatible Implementation of a specification, we are welcoming and encouraging other implementations of the specification and are avoiding singling out or favoring particular implementations or a vendor.
Self-certification: The certification process for EFSP we utilize a self-serve model, thus lowering the costs and effort involved in carrying out certifications. There is an explicit requirement for all test results to be made publicly available so verification can be carried out.
Specification processes’ are, by their nature, involved, detailed, and fairly complex. Care has been taken to ensure the overhead associated with engaging in the spec process is no more significant than it needs to be. But, we will learn as we progress, and expect to tweak the process further based on this ongoing learning.
We hope you’ll get involved!