Skip to main content
  • Log in
  • Manage Cookies
Eclipse Foundation
Download
  • Projects
  • Working Groups
  • Members
  • Community
    • Marketplace
    • Events
    • Planet Eclipse
    • Newsletter
    • Videos
    • Blogs
  • Participate
    • Report a Bug
    • Forums
    • Mailing Lists
    • Wiki
    • IRC
    • Research
  • Eclipse IDE
    • Download
    • Learn More
    • Documentation
    • Getting Started / Support
    • How to Contribute
    • IDE and Tools
    • Newcomer Forum
  • More
      • Community

      • Marketplace
      • Events
      • Planet Eclipse
      • Newsletter
      • Videos
      • Blogs
      • Participate

      • Report a Bug
      • Forums
      • Mailing Lists
      • Wiki
      • IRC
      • Research
      • Eclipse IDE

      • Download
      • Learn More
      • Documentation
      • Getting Started / Support
      • How to Contribute
      • IDE and Tools
      • Newcomer Forum
  1. Home
  2. Blogs
  3. Tanja Obradovic's blog
  4. How is the Eclipse Foundation Specification Process (EFSP) different from Java Community Process (JCP)?

How is the Eclipse Foundation Specification Process (EFSP) different from Java Community Process (JCP)?

Monday, November 26, 2018 - 14:40 by Tanja Obradovic

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!

Tags: 
Eclipse Foundation Specification Process
EFSP
Java Community Process
jcp
java ee
Jakarta EE
Specification
Specification Process
  • Tanja Obradovic's blog
  • Sign in to post comments.

Eclipse Foundation Blogs

  • Ian Skerrett (857 posts)
  • Wayne Beaton (796 posts)
  • Mike Milinkovich (286 posts)
  • Benjamin Cabé (131 posts)
  • Ivar Grimstad (97 posts)
  • Tanja Obradovic (38 posts)
  • Thabang Mashologu (31 posts)
  • Christopher Guindon (15 posts)
  • Roxanne Joncas (14 posts)
  • Paul Buck (11 posts)
  • Frédéric Desbiens (11 posts)
  • Mikaël Barbero (9 posts)
  • Jameka Woodberry (9 posts)
  • Hudson Kelly (8 posts)
  • Brian King (6 posts)
  • Denis Roy (5 posts)
  • Gabriela Motroc (4 posts)
  • Gael Blondelle (3 posts)
  • Shabnam Mayel (3 posts)
  • Shanda Giacomoni (1 posts)
  • Paul White (1 posts)
  • Jacob Harris (1 posts)
  • Stephanie Swart (1 posts)
  • Michael Plagge (1 posts)
  • Sharon Corbett (1 posts)

Recent blog posts

  • Member Case Study: itemis Builds Its Automotive Industry Business
  • Why I’m Running for the OSI Board of Directors
  • Welcome jadeva GmbH to the Jakarta EE Working Group!
  • Credentials leaked on GitHub
  • Hashtag Jakarta EE #61
  • Eclipse Cloud DevTools Community Update - February 2021
  • Hashtag Jakarta EE #60
  • The 2021 Eclipse Community Newsletter Calendar
  • Hashtag Jakarta EE #59
  • Jakarta EE Marketing and Branding Committee Levels-Up with New Members
More

Eclipse Foundation

  • About Us
  • Contact Us
  • Donate
  • Members
  • Governance
  • Code of Conduct
  • Logo and Artwork
  • Board of Directors

Legal

  • Privacy Policy
  • Terms of Use
  • Copyright Agent
  • Eclipse Public License
  • Legal Resources

Useful Links

  • Report a Bug
  • Documentation
  • How to Contribute
  • Mailing Lists
  • Forums
  • Marketplace

Other

  • IDE and Tools
  • Projects
  • Working Groups
  • Research@Eclipse
  • Report a Vulnerability
  • Service Status

Copyright © Eclipse Foundation. All Rights Reserved.

Back to the top