Eclipse Foundation Specification Process(EFSP)与Java Community Process(JCP)有何不同?

Eclipse

前不久Oracle宣布新版本的Java将不再包含Java EE 。这样做使得Java更加轻量化,说白了就是在减轻自身成本,而后又宣布Java将在2019年收费,不得不说,这波操作真的很6。关于Java收费的问题我们会在近期更新的文章中深入探讨。而将JavaEE转交给了 eclipse基金会去管理。接收JavaEE项目后因为商标的问题eclipse对JavaEE进行了名称上的变更,为此还特意在社区进行了投票,结果我们熟知的JavaEE 就变成了Jakarta EE 。名称更改只是其一,更重要的Jakarta EE 由原本的 JCP规范转变为了 eclipse的 EFSP规范。eclipse官方的博客中就此做了简单的阐述,我们一起来了解下。

—-译文—-

目前为止Oracle官方已经将企业级Java平台JavaEE转交给了eclipse基金会。社区决定将Java EE规范重命名为Jakarta EE。 这种向开源的巨大转变的一部分是改变规范过程。Java Community Process(JCP)将被Eclipse Foundation Specification Process(EFSP)取代,它将更适合供应商中立性,透明度以及与开源相关的所有其他属性。 那究竟有什么不同呢?

EFSP和JJCP之间存在许多差异,其最主要的五点差异如下图:

JAVA JCP与EFSP对比

代码优先:虽然JCP建议首先创建一个规范文档,但EFSP将首先基于动手实验和编码,以证明某些内容值得在规范中进行记录。

协作:EFSP由Jakarta EE工作组成员定义和管理,该成员作为供应商中立组管理,并将由更广泛的Jakarta社区用于规范创建和实施。通过协作确保工作组中每个人参与规范创建的公平竞争环境。

文档和TCK是开源的:EFSP的主要优点是生成开源的文档和TCK。这意味着社区的以下内容:透明度,开放性,共享负担和供应商中立性。您可以参考此开源TCK博客以获取更多见解。向社区开放规范并让它们影响技术方向并提供反馈,这使得大量人员能够参与进来,从而最终提高质量!透明度,开放性,供应商中立性不是JCP的一部分。

兼容的实现:JCP要求每个规范版本都有相应的参考实现。 EFSP将要求至少一个规范的兼容实现,我们欢迎并鼓励规范的其他实现,并且避免单独或偏向于特定实现或供应商。

自我认证:EFSP的认证过程我们使用自助服务模式,从而降低了执行认证所涉及的成本和工作量。明确要求将所有测试结果公之于众,以便进行验证。

规范过程本质上涉及,详细和相当复杂。已经注意确保与参与规范过程相关的开销并不比它需要的更重要。但是,随着我们的进步,我们将学习,并期望在此持续学习的基础上进一步调整过程。

我们希望您能参与其中!

—-原文—-

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

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!

原文地址:https://blogs.eclipse.org/post/tanja-obradovic/how-eclipse-foundation-specification-process-efsp-different-java-community