这篇文章主要介绍“java中的OpenJDK是什么”，在日常操作中，相信很多人在java中的OpenJDK是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”java中的OpenJDK是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名注册、雅安服务器托管、营销软件、网站建设、黄骅网站维护、网站推广。
OpenJDK 是 Java 平台标准版 (Java SE) 的免费开源实现。这是 Sun Microsystems (以下简称：Sun) 于2006年开始努力的结果。该实现已获得 GNU通用公共许可证（GNU GPL）版本2的许可。但有链接例外。除 GPL 特例链接之外，链接到 Java 类库的组件将受到 GPL 许可条款的约束。
OpenJDK Project 产生了许多组件：最重要的是虚拟机( HotSpot )，Java类库和Java编译器( javac )。
从 Java SE 7 开始，OpenJDK Project 产出的 OpenJDK 成为了 Java SE 的官方参考实现。
从 Java SE 10 开始，JDK Project（ OpenJDK Community 的下属项目） 产出的 OpenJDK 成为了 Java SE 的官方参考实现。
没错，从 Java SE 7开始往后的版本，连大名鼎鼎的 Oracle JDK 都是根据 Open JDK 做出来的(修改了一些功能的实现方式，再打上自己的商标并提供配套服务)。或者应该说自 Java SE 7开始往后的版本，所有的 JDK 都源自于 Open JDK(OpenJDK 与 其他 JDK 的关系就和 Linux 与它的众多发行版是一样一样的)。
OpenJDK 是由 OpenJDK Community 、Oracle、IBM 领导，连同 Alibaba，Amazon，Ampere，Azul，BellSoft，Canonical，Fujitsu，Google，Huawei，Intel，Java Community，JetBrains，London Java Community，Microsoft，Red Hat，SAP，SouJava，SUSE，Tencent，Twitter ，VMWare 等第三方共同开发、维护的 Java SE 开源参考实现。
OpenJDK 具体版本的开发标准是 Java Community Process（JCP，Java 社区进程） 发布的 Java Specification Requests（JSR，Java规范请求）。
OpenJDK Community 领导的 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）产出的 OpenJDK 是 Java SE 的官方参考实现，只产生 OpenJDK 源码，并不提供可以直接使用的二进制文件格式。现在能直接使用的二进制文件格式的 JDK 都是被编译之后的程序。OpenJDK 官网指向的可下载二进制文件的地址，实际是 Oracle’s OpenJDK builds 下载的地址。没错，这也是被 Oracle 编译后的版本。
OpenJDK 使用 Git 在GitHub 的开源地址，OpenJDK 使用 Mercurial 在 OpenJDK 的开源地址
1995年5月23日，Sun 公司在 Sun world 会议上正式发布 Java。
1996年1月23日，Sun 公司发布了 Java 的第一个开发工具包。
Sun 在 JavaOne 2006 中宣布 Java 将成为开源软件并建立了 Open JDK 社区。
2006年11月13日 Sun 根据 GNU 通用公共许可证 将 Java HotSpot 虚拟机和编译器作为免费软件发布，并承诺将在2007年3月之前将其余的 JDK（包括Java运行时环境）置于 GPL 之下。
Sun 承诺在2007年上半年发布几乎完全基于免费和开源代码的 Java 开发工具包（JDK）。
2007年5月8日 Sun 在 GPL 下发布了 Java 类库的完整源代码。
2007年，除了一些被第三方授权给 Sun 且 Sun 无法根据 GPL 重新授权的受限部分之外，被限制的部分列表中还包括 Java 图形用户界面（GUI）的几个主要组件。Sun 表示计划用替代的实现方式替换其余的私有组件，并使类库完全免费。
在最初2007年5月发布时，OpenJDK 类库仍然有4％是私有的。到2008年5月OpenJDK 6出现时，只剩下不到1％（SNMP 实现，它不是 Java 规范的一部分）是私有的，使得无需任何二进制插件即可构建 OpenJDK。二进制插件要求后来在2009年4月将 b53 从 OpenJDK 7 中删除。
OpenJDK 6 Project，基于JDK 7，但经过修改(删除 Java 7 的特性)后提供了Java 6的开源版本。
OpenJDK 7 Project，于2011年7月28日发布GA(General Availability，一般可用性)版本。 OpenJDK 7 Update Releases Project，该项目在 OpenJDK 7 初代GA版本的基础上提供更新。
OpenJDK 8 Project，于2014年3月18日发布GA版本。 OpenJDK 8 Update Releases Project，该项目在 OpenJDK 8 初代GA版本的基础上提供更新。
OpenJDK 9 Project，于2017年9月21日发布GA版本。
JDK Project（ OpenJDK Community 下属项目）： (这个长期运行的项目的目标是生成一系列 Java SE 平台的开源参考实现，正如 Java Community Process 中的 JSR 所指定的那样。根据一个严格的、基于时间的模型，该项目每六个月发布一个特性版本） OpenJDK 10，于2018年3月20日发布GA版本。 OpenJDK 11，于2018年9月25日发布GA版本。 OpenJDK 12，于2019年3月19日发布GA版本。 OpenJDK 13，于2019年9月17日发布GA版本。 OpenJDK 14，于2020年3月17日发布GA版本。 OpenJDK 15，于2020年9月15日发布GA版本。 OpenJDK 16，于2021年3月16日发布GA版本。 OpenJDK 17，目前正在开发中，预计于2021年9月14日发布GA版本。
JDK Update Releases Project（ OpenJDK Community 下属项目）： (该项目的目标是为 JDK Project 开发更新） OpenJDK 11 Update Releases，在 OpenJDK 11 初代GA版本的基础上提供更新。 OpenJDK 12 Update Releases，在 OpenJDK 12 初代GA版本的基础上提供更新。 OpenJDK 13 Update Releases，在 OpenJDK 13 初代GA版本的基础上提供更新。 OpenJDK 14 Update Releases，在 OpenJDK 14 初代GA版本的基础上提供更新。 OpenJDK 15 Update Releases，在 OpenJDK 15 初代GA版本的基础上提供更新。 OpenJDK 16 Update Releases，在 OpenJDK 16 初代GA版本的基础上提供更新。
OpenJDK Community 是一个开发人员协会，他们在 Java Community Process 定义的Java平台标准版（Java SE）的当前版本和未来版本的开源实现以及密切相关的项目上进行协作。这些规章制度的目标是通过允许和鼓励社区成员以公开、透明和精英的方式行事，促进社区的长期健康和发展。
OpenJDK Community 由一组团体和一组项目组成，这些团体是一组就共同兴趣进行公开对话的个人的集合，而这些项目是共同努力以产生特定工件的。 有社区范围的一般角色，以及特定于组和项目的角色。
理事会管理社区的结构和运作，根据序言中规定的原则监控社区的健康。 它坚持并维护这些章程，解决程序纠纷，并确保有足够的基础结构可用。 理事会对技术或发布决策没有直接权力。
参与者是订阅了一个或多个 OpenJDK 邮件列表的个人。参与者可以将消息发布到列表中，提交简单的补丁，以及做出其他类型的小贡献。
贡献者是签署了甲骨文贡献者协议 (Oracle Contributor Agreement，OCA) 的参与者，或者为签署了该协议或同等协议的组织工作，并在该工作范围内根据该协议做出贡献。贡献者可以提交比一个简单的补丁更大的更改，可以提出新的项目，可以在组和项目中担任不同的角色。
如果贡献者的就业情况发生了变化，使得贡献者不再被OCA或其同等产品覆盖，那么贡献者必须通知 OpenJDK 主管，从而放弃这个角色。
任何集团成员或提交者都可被现有的 OpenJDK 成员提名为 OpenJDK 的成员。这样的提名必须得到 OpenJDK 成员至少三票同意。
任何 OpenJDK 成员都可以提出删除另一个 OpenJDK 成员的动议。这样的动议必须由 OpenJDK 成员的三分之二多数票（赞成票至少是否票的两倍）批准，而作为动议主题的成员弃权。
在特殊情况下，理事会可以以三分之二多数票（赞成票至少是否票的两倍）罢免 OpenJDK 成员。
每一个 OpenJDK 成员资格在一年后会自动到期，但会根据要求续订。续展申请必须在期满一年内收到。除非需要 OpenJDK 成员资格的角色可以保留，否则成员资格已过期且尚未续期的 OpenJDK 成员不能行使成员资格特权。
如果一个 OpenJDK 成员的就业情况发生了变化，这样的贡献将不再被 OCA 或它的同等物覆盖，那么成员必须通过通知 OpenJDK 主管放弃贡献者角色。此时，成员资格将被视为已过期。
The OpenJDK Members Group 由所有 OpenJDK 成员组成。OpenJDK 负责人是其组织的负责人。解散组，添加和删除组成员以及选择和删除组负责人的通常规则不适用于 OpenJDK Members Group 。
OpenJDK 主管是一个 OpenJDK 成员，由 Oracle 任命，他指导社区的主要工作，这些工作是 Java SE 平台的新实现，称为 JDK Release Projects。OpenJDK 主管负责这些项目中使用的开发过程的公开性和透明性，并且还可以解决某些类型的程序纠纷。OpenJDK 主管是理事会成员。
Governing Board (GB，理事会)管理 OpenJDK Community 的结构和操作。
JDK Release Projects 是Java SE平台实现的新版本项目。此类项目只能由 OpenJDK 主管提议，并且只能由 GB 赞助。OpenJDK 主管是所有 JDK Release Projects 的项目负责人。每个 OpenJDK 成员都有机会提出要包含在 JDK Release Projects 中的特性，并且关于要包含哪些特性的决定将以透明的方式做出。
GB 由五个出资人组成：
主席，由Oracle任命；
副主席，由IBM任命；
OpenJDK 主管由Oracle任命；
两名普通成员，由 OpenJDK 成员提名和选举。
GB 的普通成员由 OpenJDK 成员投票选出。普通成员的任期为一个日历年，从每年的4月1日开始。
在为期两周的提名期内，任何 OpenJDK 成员都可以提名目前没有被任命 GB 理事席位的个人来填补一个普通成员席位。该个人不必已经是 OpenJDK 成员。OpenJDK 成员可以做出多个这样的提名。
GB 在某种程度上是一个立法机构：它有权修订这些章程，以完善现有流程，定义新流程以及处置不再需要的流程。对这些章程的任何修订都必须获得理事会绝对三分之二多数票（赞成票至少是否票的两倍，且总票数至少有三张票）的批准，然后由 OpenJDK 成员的三分之二批准。
GB 在某种程度上也是司法机构：它有权解决共同体内可能发生的任何程序性纠纷。如本细则所述，个人做出的任何程序性决定均可向 GB 提出上诉。如果 GB 决定听取上诉，则提议的判决必须经简单多数投票批准。
GB 不是一个执行机构：它对技术或发布决定没有直接的权力。对于任何给定的项目，该权限由该项目的负责人持有（特别 OpenJDK 领导的 JDK Release Projects）。
GB 是一个小组，由主席主持。这使 GB 可以赞助项目。解散组，添加和删除组成员以及选择和删除组负责人的通常规则不适用于 GB。
GB 不得少于五个人。 它应始终包括主席，副主席，OpenJDK 主管和至少两个如上所述的普通成员席位。
GB 可以以绝对多数票投票通过，增补或撤消任命的和普通成员的 GB 席位。
GB 可以通过投票邀请特定个人作为观察员参加 GB 会议 。这样的人不必是 OpenJDK 成员。我们欢迎观察员倾听并为对话做贡献，但他们没有任何投票权。GB 可通过投票罢免观察员。
如果 GB 成员真诚地反对 OpenJDK 主管做出的技术或发布决定，可以提出上诉。
GB 应对所有社区团体和项目进行年度审查，以消除被确定为无效的任何此类活动。
Java Community Process（JCP）成立于1998年，是一种正式的机制，允许感兴趣的各方开发Java的标准技术规范。 只要填写JCP网站上的表格，任何人都可以成为JCP会员。 组织和商业实体的JCP成员资格需要年费，但个人免费。
JCP 是国际 Java 社区标准化和批准 Java 技术规范的过程。JCP 确保使用基于共识的包容性方法来开发高质量的规范。JCP 批准的规范必须随附参考实现（以证明可以实现规范）和技术兼容性套件（用于测试实现是否符合规范的一套测试，工具和文档）。
任何 Java 技术的增强或新技术的引入都通过 Java Specification Request （JSR）进行。
个人无需签署正式的 JCP 成员协议即可观察和评论专家组的活动，因为他们可以利用 JCP 的透明度机制，例如公共邮件列表和问题跟踪工具。
有关如何提供反馈的信息可以在 JSR 的协作项目页面上找到（在 jcp.org 的 JSR 页面上提供了指向该页面的指针）。观察者没有资格参加专家组，竞选 EC 委员或参加 JCP 的年度选举。
不愿意或无法签署 JSPA 的个人可以签署准成员协议以参加 JCP 的活动。（组织不符合此类成员资格。）准成员协议比 JSPA 更简单，并且仅涉及个人IP承诺。无需雇主签名。
准成员不能担任特别负责人，不能加入专家组或竞选 EC 委员。他们有资格投票的 EC 的准席位，但没有资格投票批准或选举席位。根据 Spec leader 的酌情决定权，准成员可以被列为 JSR 的贡献者，从而得到正式认可。
不愿意或无法（因为它们不是合法实体）签署 JSPA 的非营利组织（例如 Java 用户组）可以签署简化的合作伙伴成员协议，该协议的重点是与 JCP 成员和 PMO 合作促进 JCP 活动。
合作伙伴成员不能担任规范负责人或不能在大多数专家组中任职，但有资格竞选 EC 委员。如果被选出，则可以作为 EC 委员来担任 JSR 专家组的成员，这些专家组的重点是重新定义 JCP 的组织和“宪法”。合作伙伴成员具有与正式会员相同的投票权。
这类成员是开放的公司，非营利组织的法人实体，个体户和失业的个人，学生和一些受雇的个人。JSPA 是正式成员的成员协议。如果非就业个人和大学教职人员能够合法授权他们自己的知识产权，并因此能够代表自己签署 JSPA，那么他们就有资格成为正式成员。雇主如愿意签署雇主供款协议(大学职员无需签署雇主供款协议)，雇员便可成为正式成员。这些个人应使用其雇员电子邮件地址而不是个人电子邮件地址进行注册，以便 PMO 能够跟踪就业状况的变化。他们还应同意在更换雇主时通知 PMO。
正式成员可以充当规范负责人，加入专家组，并竞选 EC 的任何级别的席位。正式成员可投票选举 EC 的批准和选举席位，但不得投票选举准席位。
与正式成员有合同关系的雇员和其他个人可以被正式成员授权在JCP中代表其利益，作为 Spec leader，在专家组服务，或竞选 EC。这些成员应以其雇员电邮地址而非个人电邮地址登记，以便 PMO 能追踪雇员的变动。他们还应同意在更换雇主时通知 PMO。
Executive Committee (EC，执行委员会)是在 JCP 中指导 Java 技术发展的成员组。EC 既代表主要利益相关者，又代表 Java Community 的代表性部门，监督 JCP 内 Java 技术的发展和演变。
EC 负责选择要在 JCP 中进行开发的 JSR，批准规范草案供公众审查，并协调规范及其相关测试套件之间的差异，对完成的规范及其相关的 RI 和 TCK 给予最终批准，审查和批准维护版本，对第一阶段的 TCK 测试申诉做出决定，批准成员之间的维修职责转移，为 PMO 和 JCP Community 提供指导。
EC 委员必须分析、评论、投票，并决定批准提交给该计划的所有 JSR。除了负责指导整个平台的演变外，EC 和整个 JCP 计划还负责 JCP 计划本身，使它遵守社区对该计划及其成员的期望。
根据 JCP Process Document 2.11.10（2019年7月21日）的规定在2020年的年度选举中，两个批准的席位和一个选举席位将被取消，从而将 EC 的委员席位减少到18个。
永久席位---1个---由 Oracle 拥有；
批准席位---11个；
选举席位---4个；
准席位---2个；
委员的任期为2年，任期错开，所以17个席位中每年都有一半的席位可以选举。
在适当考虑到平衡的社区和区域代表性的情况下，PMO 提名成员填补空缺的批准席位。
正式成员和合作伙伴成员将投票表决，在14天的投票期内批准每位被提名人。
被提名者得到投票人的简单多数批准(赞成比反对多)。
如果一个或多个被提名人未经表决获得批准，PMO 应视需要提名额外成员，并举行额外的批准投票，直至空缺席位得到填补。
投票前六周，PMO 应在 JCP 公开选举投票站上张贴对候选人将在选举期间提供的所有材料（候选人声明，立场文件等）的完整描述。同时，PMO 将宣布接受提名的时间至少为14天。
正式成员和合作伙伴成员可以提名自己竞选这些席位。被提名者必须具体说明他们是在提名自己竞选选举席位还是准席位。
JCP 成员的雇员不能自行竞选，PMO 将拒绝此类提名。
提名期结束后，PMO 将发布所有被提名人的姓名。
在投票期间，议员可以投票给与空缺席位一样多的被提名人。（正式成员和合作伙伴成员可投票选举选举席位；准会员可投票选举准席位。）
得票最多的提名人应填补空缺席位。
如果只有一个空缺的提名人，则应给予选民投票的机会？或没有？对于那个候选人。当选的候选人必须获得简单多数。
如果没有候选人填补空缺，EC 可选择保留这个空缺，直至下一次选举。
| 委员 | 任期结束 |
|---|---|
| Alibaba | 2022,批准席位 |
| ARM | 2021,批准席位 |
| BellSoft | 2022,批准席位 |
| Marcus Biel | 2021, 准席位 |
| BNY Mellon | 2022, 批准席位 |
| Eclipse Foundation | 2022, 选举席位 |
| Ken Fogel | 2022, 准席位 |
| Fujitsu Limited | 2021, 批准席位 |
| JetBrains | 2022, 批准席位 |
| IBM | 2021, 批准席位 |
| Intel | 2021, 批准席位 |
| London Java Community | 2022, 选举席位 |
| MicroDoc | 2022, 批准席位 |
| Oracle | 永久席位 |
| SAP SE | 2022, 批准席位 |
| SouJava | 2021, 批准席位 |
| Tomitribe | 2021, 选举席位 |
| 2021, 选举席位 |
Java Specification Request （JSR）是一个正式的、开放的对Java平台的建议和最终规范的实际描述，由个人或组织向Java Community Process（JCP）提出。它包含对Java技术平台的建议更改，添加或改进。
一个或多个正式成员可以通过 JCP 网站提交 JSR 提案，以发起制定新规范或对现有规范进行重大修订的请求。
每个 JSR 必须提供以下信息：
提出请求的成员（提交者），拟议的规范负责人，专家组的初始成员以及潜在贡献者的姓名；
拟议规范的描述；
开发或修改它的原因；
主要平台版本，以及对其他平台版本的任何考虑；
预计的开发进度；
任何可以作为起点的现有文档、技术描述或实现；
一个透明性计划，它概述了规范负责人在开发规范期间将使用的工具和技术，以便与 JCP 成员和公众进行沟通，并寻求反馈。
JSR 是否是迭代的，如果是，则预期的迭代周期。
由 PMO 酌情决定，可能要求 JSR 提交的内容包括完整的 JSR 审查流程问卷或演示文稿，其中提供有关 JSR 目标以及专家组计划在其开发过程中使用的流程的信息。
现有的规格以及它们相关的 RI 和 TCK 由指定的维护负责人使用本文档中介绍的过程进行维护。在遵守 JCP 成员关于改进的愿望的同时，维护负责人应长期承担规范，RI 和 TCK 的所有权。因此，维护线索应是对其规格进行所有重大修订的规范线索，但他们无权决定何时进行重大修订。这应由 EC 响应任何 JCP 成员可以发起的 JSR 修订版来决定。提交者应做出合理的努力来招募前专家组的成员，以加入任何此类修订工作。
对Java编程语言、Java 空间中的Java虚拟机（JVM）、Java本机接口（JNI）模块和包，或仅作为 Java SE 一部分交付的其他包的更改，如果跨平台版本执行的不一致，可能会严重破坏安装基础。为了保护已安装的用户群，任何此类更改都只能在 Java SE 的伞形 JSR 中接受和执行。
为了防止出现碎片，新的平台版本规范不得实质性地复制现有平台版本或概要文件。
所有新的或修订的规范必须与目标平台版本规范的最新版本兼容。为了实现此目的，所有定义新的概要文件规范或修订现有概要文件规范必须参考其所基于的平台版本规范的最新版本，或者引用正在通过活动 JSR 开发的该规范的更新版本。
需要 JSR 提交来说明 JSR 的 RI 和 TCK 是作为概要文件还是平台版本的一部分，以独立方式或两者同时提供。关于特定 JSR 是否包含在概要文件或平台版本中的最终决定由概要文件或平台版本 JSR 的规范负责人和专家组做出的相关 JSR 的 EC 选票确认。如果概要文件或平台版本的规范主管拒绝了包含请求，则 JSR 必须提供独立的 RI 和 TCK 。
在最初独立交付后，可以将技术合并到概要文件或平台版本中。提议成为概要文件或平台版本的一部分并考虑停止独立可用性的新版 API 的 JSR 必须说明进行此更改的理由，并且必须告知公众要终止独立 RI 的意图，并且 TCK 提前发布了一个 JSR。
当收到 JSR 时，PMO 将为其提供一个跟踪号，创建其 JSR 页面，向公众公布拟议的 JSR，并开始进行JSR 审查。对 JSR 的评论应通过 JSR 的公众反馈交流机制提供。意见应转发给 EC 进行审议，并应在JSR 页面上提供（类似意见可以合并）。
有兴趣加入专家组或作为贡献者参与的成员应通过告知规范负责人和 PMO 来表明自己的身份。我们鼓励规范负责人在此期间积极招募小组成员和贡献者，并用希望提供帮助的人的名字更新 JSR 页面，因为表现出对 JSR 的广泛兴趣和代表性的多样性将大大增加 EC 批准它的机会。
如果在批准 JSR 之前担任规范负责人的成员退出了 JCP，PMO 将要求初步专家组选择一名替代者。
规范负责人负责开发参考实现和技术兼容性工具包，并按照 JSPA 中的说明为其授予许可。规范负责人必须在 JSR 评审开始之前向 EC 提供建议的规范，RI 和 TCK 许可证的完整副本。PMO 将在 JSR 页面上发布许可证。EC 委员应提供有关条款的反馈，以表明整个社区对条款的反应。如果 EC 委员认为拟议的许可条款与 JCP 内使用的许可指导方针不兼容，则对提议的 JSR 的投票应延迟到 Oracle 法律机构对此事发表意见之前。
在 JSR 审查之后，EC 委员应审查 JSR 和收到的任何评论，并投票决定是否应批准 JSR。
如果 JSR 批准投票失败，PMO 应将所有 EC 评论发送给 JSR 提交者，后者可以修改 JSR 并在14天内重新提交。如果在此期间未收到修订的 JSR，则原始 EC 决定生效， JSR 应予关闭。如果收到修订的 JSR，则 PMO 应将其发布到 JSR 页面，向公众公布修订的 JSR，然后将其发送给所有 EC 委员以进行 JSR 复议投票。如果投票失败，则关闭 JSR。
在获得 JSR 批准后，PMO 指示规范负责人正式创建专家组，并确定将充当贡献者的成员。PMO 将相应地更新 JSR 页面。
对于迭代 JSR，规范负责人可以在最终发布更新 JSR 的意图之前的任何时间通知 PMO。规范负责人应提供下一次迭代的开始日期，下一次迭代的时间表，下一次迭代的版本号以及专家组的建议的初始成员。将为迭代创建一个新的 JSR，具有相同的 JSR 详细信息以及新的专家组成员，版本号和时间表。迭代可能会重叠；在创建下一个迭代之前，不需要上一个迭代达到任何特定的里程碑。除了更改计划和版本之外，规范负责人成员还可以提名另一位 规范负责人代表。无需为第一次或以后的迭代续订迭代的 JSR 而进行 JSR 批准投票，除非规范负责人建议 PMO 认为对 JSR 提交的更改是实质性的。迭代 JSR 可能遵循维护阶段流程。
专家组应在开始工作时考虑 JSR 中提出的要求、任何贡献的文件或技术说明，在 JSR 审查期间收到的意见，以及如果是对现有规范的修订，则由维护负责人维护的问题清单来开始工作。可以从与其他成员，行业团体，软件开发人员，最终用户和学者的讨论中获得其他意见。贡献是根据 JSPA 的条款进行的。目的是定义需求，然后编写规范和原型参考实现草案，以供社区和公众审查。
我们鼓励 JSR 在开发过程中经常提供规范和参考实现的公共草案，即使它们不完整。草案应以 PMO 批准的方式公开发布，并且在新的草案可用时，规范负责人应通知 PMO。规范负责人应提供一种机制，通过这种机制他们将草案通知公众，公众可以对这些早期草案提供反馈意见。
当规范的公众评审草案准备就绪时，规范负责人应将草案发布，并将草案以及需要评审的任何其他文件发送给 PMO，PMO 将在网上发布这些文件，供公众下载。此时，JCP 成员的社区评审同时进行。当 PMO 宣布可提供规范草案以供公众评审和评论时，公共审查就开始了，该草案可根据 PMO 的决定在评估许可下托管在另一个站点上。
规范负责人负责确保阅读并考虑所有评论。如果这些意见导致对规范草案的修订，并且这些修订导致重大修改(专家组认为) ，那么规范负责人必须在投票开始前至少3天张贴更新的草案，并将更新后的草案(连同修改摘要)发送给 PMO。PMO 应在投票开始之前将新的草案和变更摘要张贴在 JCP 网站上，并应通知公众新的草案可用。
除非“规范负责人”希望在“最终批准投票”之前发布另一份“公共审核”，否则“公共审核最终批准”投票将在“公共审核”结束时开始。投票结束时，PMO 应将 EC 成员提交的所有评论连同投票一起分发给专家组。
如果公共审核最终批准规范投票失败，则专家组将有30天的时间来响应 EC 提出的问题更新草案并将修订后的版本提交 PMO。如果在30天内未收到修订的草案，则 EC 原决定生效，PMO 将宣布 JSR 已关闭。如果收到修订，PMO 应将其转发给 EC 并启动“公共审核最终批准规范重新审议”投票。投票结束时，PMO 应将 EC 成员提交的所有评论连同投票一起分发给专家组。如果投票失败，则将关闭 JSR，并且解散专家组。如果 JSR 是对现有规范的修订，则规范负责人应恢复当前规范的维护负责人的角色。
如果专家组认为这会有所帮助，则可以进行多次公开草案和审核。
如果公众审查最后批准投票(或复议投票)成功，专家组应通过完成其认为对意见作出必要修改的方式编制最终规范草案。
规范负责人负责完成 RI 和 TCK。需要针对多个平台的 JSR 来支持每个环境，这可能需要为每个环境提供单独的 RI 和 TCK。如果 RI 和 TCK 发现规范中定义不足、不完整或模棱两可的地方，规范负责人应与专家组合作纠正这些缺陷，然后将修订后的规范连同变更摘要一起发送给 PMO。信息应发布在 JCP 网站上。专家组应继续审议在此期间收到的任何进一步意见。
规范负责人还负责建立一个明确定义的一级 TCK 申诉程序，以应对 TCK 中包含的测试挑战。此过程必须在 TCK 文档中描述。对初级决策不满意的实施者应通过向 PMO 发送电子邮件，记录他们的担忧，向 EC 申诉。PMO 将把请求连同从管理层收到的关于初级决定理由的任何信息一起分发给 EC，并发起为期7天的申诉投票。
根据问题的性质，一个成功的 TCK 挑战将需要更新 TCK、规范和 RI 中的一个或多个。在 TCK 上诉投票成功结束后的30天内，维护负责人必须在必要时更新这些可交付成果，并在将规范(如果更改了)和更新后的 RI 或 TCK 的 URL 在 JCP 网站上发布时向 PMO 报告这些更改。
当专家组确信 TCK 提供了足够的测试覆盖范围，RI 正确地执行了规范，RI 通过了 TCK，规范负责人应将规范的最终草案连同关于 EC 委员如何获得 RI 和 TCK 进行评估的说明一起发送给 PMO。PMO 应向 EC 分发材料，并公布最终版本。EC 的任何意见应由 PMO 送交专家组。
为了协助 PMO 跟踪“活跃 JSR ”的数量，在提交最终材料时，规格负责人应通知 PMO，是否期望通过维护版本或新的后续 JSR 进一步开发 JSR。作为最终版本的一部分提交的 TCK 必须满足以下要求：
包括关于 TCK 的配置和执行的文件、使用 TCK 所需的任何其他信息(例如所提供的任何工具的文件)、第一级 TCK 上诉程序的定义和说明，以及除了通过 TCK 测试之外必须满足的兼容性要求
兼容性要求至少必须指定所有兼容的实现
完全实施规范，包括所有必需的接口和功能，以及不得修改、子集、超集或以其他方式扩展许可方名称空间，或在许可方名称空间中包含任何模块、公共或受保护包、类、 Java 接口、字段或方法，但实现的规范或规范所要求/授权的除外。
除非规范或 TCK 明确允许例外，否则必须满足这些要求。
附有测试工具，脚本或其他方式，以自动化测试执行和结果记录。
包括一个 TCK 覆盖范围文档，该文档将帮助 EC 委员评估 TCK 的质量。该文档应包括对 TCK 中包含的文档的概述，对用于验证 TCK 质量的方法的描述，用于衡量规范的 TCK 测试覆盖率的标准，所达到的测试覆盖率编号以及充分性的依据 TCK 质量及其测试范围。
提供100％签名测试覆盖率。这些测试必须确保完全实现了规范要求的所有 API 签名，并且仅将规范要求的 API 签名包括在 JSR 的命名空间中。
TCK 许可条款必须允许实施者自由和公开地与所有有关方面讨论测试过程和详细的 TCK 测试结果。
EC 成员可以在7天内提出异议。异议必须仅限于认为公开审查和最终审查之间的具体变化太大而不能被视为更正或澄清的声称。PMO 将评估异议要求，如果得到证实，规格负责人将有30天的时间响应 EC 的要求修改规范，RI 和 TCK，并将修改后的材料重新提交给 PMO。
如果在30天内未收到任何回复，则 EC 原决定生效，PMO 将关闭 JSR，专家组将解散。如果 JSR 是对现有规范的修订，则规范负责人应恢复当前规范的维护负责人的角色。
如果收到答复，则 PMO 应将其分发给所有 EC 委员以进行最终批准复议投票。投票结束时，EC 委员提交的所有投票意见应由 PMO 分发给专家组。如果复议投票失败，JSR 将被关闭，专家组将解散。如果 JSR 是对现有规范的修订，则规范负责人将恢复当前规范的维护负责人的角色。
在收到最终发布材料的14天内，PMO 应在 JCP 网站上发布规范和有关如何获取 RI 和 TCK 的信息的链接，并应向成员和公众宣布这些材料的可用性。已发布的 TCK 信息必须包括任何利害关系方免费获得 TCK 文档副本的方法。最终版本发布后，专家组将完成其工作。规范负责人通常将成为维护负责人，并可以请专家组成员和其他人员担任该角色。
维护负责人必须确保到 RI 和 TCK 的链接仍然有效。如果链接不起作用，则维护负责人将在 PMO 通知后的30天内进行更正。如果问题未得到纠正，PMO 将启动 JSR 撤回投票（如果尚未完成维护发布）或维护发布撤回投票（如果已进行维护发布），以确定是否应判定维护负责人已放弃 JSR。如果投票通过，则 JSR 本身或相关的维护版本将被标记为已撤回。
| Build | LTS | 宽松式许可证 | 经过 TCK 测试 | 未修改上游的构建 | 提供商业支持 |
|---|---|---|---|---|---|
| AdoptOpenJDK | Yes | Yes | No | 可选 | 可选(IBM) |
| Alibaba Dragonwell | Yes | Yes | No | No | No |
| Amazon Corretto | Yes | Yes | Yes | No | 可选 (on AWS) |
| Azul Zulu | Yes | Yes | Yes | No | 可选 |
| BellSoft Liberica JDK | Yes | Yes | Yes | No | 可选 |
| Huawei bisheng JDK | Yes | Yes | 未知 | No | No |
| IBM Java SDK | Yes | No | Yes | No | Yes |
| Microsoft Build of OpenJDK | Yes | Yes | Yes | No | No (beta) |
| ojdkbuild | Yes | Yes | No | Yes | No |
| OpenLogic OpenJDK | Yes | Yes | Yes | No | 可选 |
| Oracle GraalVM Community Edition | NO | Yes | Yes | NO | NO |
| Oracle GraalVM Enterprise Edition | Yes | No | Yes | No | Yes |
| OracleJDK | Yes | No | Yes | No | Yes |
| Oracle's OpenJDK | No | Yes | Yes | Yes | No |
| Red Hat build of OpenJDK | Yes | Yes | Yes | No | Yes |
| Tencent Kona | Yes | Yes | 未知 | No | No |
| SAP SapMachine | Yes | Yes | Yes | No | 可选 (for SAP products) |
PS：
LTS：Long Term Support(长期支持版本），提供长期更新支持。
TCK：Technology Compatibility Kit是一套测试套件，至少名义上检查Java规范要求（JSR）的特定是否符合要求。 它是 Java Community Process中批准的 JSR 所需的三部分内容之一。用于检查是否兼容标准 Java SE。
OpenJDK Community 领导的 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）产出的 OpenJDK 是 Java SE 的官方参考实现，只产生 OpenJDK 源码，并不提供可以直接使用的二进制文件格式。现在能直接使用的二进制文件格式的 JDK 都是被编译之后的程序。
自 Java SE 7开始往后的版本，所有的 JDK 都源自于 Open JDK(OpenJDK 与 其他 JDK 的关系就和 Linux 与它的众多发行版是一样一样的)。所以严格意义上来说 Oracle JDK 也是 Open JDK 的一个发行版而已。
截止2021年5月8日，AdoptOpenJDK 官网的声明：
截止2021年5月8日，ojdkbuild 的 GitHub README.md 中 FAQ 的说明：
根据 OpenJDK 的 Gaining Access to the JCK 的描述：
Java 兼容性工具包（又称 JCK 或 TCK for Java SE）免费提供给计划基于从 OpenJDK 派生的代码部署兼容 Java 实现的开发人员，或者正在参与 OpenJDK 研究、错误修复、代码增强和/或到其他硬件/软件体系结构的端口的开发人员。
OpenJDK Community 会给签署了 TCK 许可协议（OCTLA）的厂商或组织提供 JCK。
要想知道一个提供商的 Open JDK build 是否通过 TCK 测试，除了看提供商自己的官方声明之外，还可以查看 OpenJDK Community 提供的 OCTLA 协议签署者列表是否有该提供商。
理论上通过了 TCK 测试的 JDK 在 Java SE 标准规范功能上是互相兼容的，为什么是 Java SE 标准规范功能才互相兼容呢？
因为有的机构在实现 Java SE 标准规范功能后，会在 JDK 中加入一些自己的特色功能，但是这个特色功能可能并不是每个 JDK 都有，所以如果在编程序时使用了某家 JDK 的特色功能，换个别家的 JDK 可能就会出现各种未知问题(个人猜测，也可能是根本跑不起来)。
其实通过了 TCK 测试的 JDK 之间互换 ，在程序只用 Java SE 的规范功能的情况下也可能存在一些小 BUG，不过确实会比没有通过 TCK 测试的要好上不少(这也没办法，正常编程有时候删个注释就无法运行，也没人能解释这种玄学问题)。
其实博主也挺讨厌这种一大篇理论性描述的文章，但是如果不把大致基本概念和各处的重要细节给描述清楚，在写结论和个人猜想的时候就又会有引出一些不必要的争吵，这些不必要的争吵又大多是因为对基本概念和各处的重要细节了解的不对等引起的。也是挺无奈的...
能看到此处的各位都是绝对的勇士，至少在没有紧急且重大的问题的时候，博主是看不下去这种长度的文章的，再次献上最高敬意，闲话就不说了，下面开始总结。
自 Java SE 7开始往后的版本，所有的 JDK 都源自于 Open JDK(OpenJDK 与 其他 JDK 的关系就和 Linux 与它的众多发行版是一样一样的)。
OpenJDK Community 领导的 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）产出的 OpenJDK 是 Java SE 的官方参考实现，只产生 OpenJDK 源码，并不提供可以直接使用的二进制文件格式。现在能直接使用的二进制文件格式的 JDK 都是被编译之后的程序。OpenJDK 官网指向的可下载二进制文件的地址，实际是 Oracle’s OpenJDK builds 下载的地址。没错，这也是被 Oracle 编译后的版本。
OpenJDK 是由 OpenJDK Community 、Oracle、IBM 领导，连同 Alibaba，Amazon，Ampere，Azul，BellSoft，Canonical，Fujitsu，Google，Huawei，Intel，Java Community，JetBrains，London Java Community，Microsoft，Red Hat，SAP，SouJava，SUSE，Tencent，Twitter ，VMWare 等第三方共同开发、维护的 Java SE 开源参考实现。
OpenJDK 具体版本的开发标准是 Java Community Process（JCP，Java 社区进程） 发布的 Java Specification Requests（JSR，Java规范请求）。
作为 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）开发标准的 JSR 是众多由 JCP 成员发起的 JSR 草案在经过：JSR 草案发起、JCP 公众评审、JSR最终定案、 JCP 的 EC 评审等步骤后，成功诞生的 JSR 聚合而成的。
下面用一张图简单概括本篇文章的要点：
由于本篇文章内容太长，OpenJDK builds 与 OracleJDK 的选择问题就留到下一章单独开一篇专门来写（不过我想认真看完这一章的朋友，应该已经清楚知道了他们的区别以及什么情况下应选择哪个版本了吧）。
到此，关于“java中的OpenJDK是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
