上一篇是分享的是《JVM 虚拟机 - 理解 Java 堆中对象调配、布局和拜访的全过程》，这篇给大家分享《OpenJDK》。
1.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 成为了 Java SE 的官网参考实现。
从 Java SE 10 开始，JDK Project（OpenJDK Community 的上司我的项目）成为了 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 的官网参考实现，只产生 OpenJDK 源码，并不提供能够间接应用的二进制文件格式。当初能间接应用的二进制文件格式的 JDK 都是被编译之后的程序。OpenJDK 官网指向的可下载二进制文件的地址，理论是 Oracle’s OpenJDK builds 下载的地址。没错，这也是被 Oracle 编译后的版本。
OpenJDK 应用 Git 在 GitHub 的开源地址，OpenJDK 应用 Mercurial 在 OpenJDK 的开源地址
2.OpenJDK 的发展史
1995 年 3 月 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 版本的根底上提供更新。
3.OpenJDK Community
OpenJDK Community 是一个开发人员协会，他们在 Java Community Process 定义的 Java 平台标准版（Java SE）的以后版本和将来版本的开源实现以及密切相关的我的项目上进行合作。这些规章制度的指标是通过容许和激励社区成员以公开、通明和精英的形式行事，促成社区的长期衰弱和倒退。
OpenJDK Community 由一组个人和一组我的项目组成，这些个人是一组就独特趣味进行公开对话的集体的汇合，而这些我的项目是共同努力以产生特定工件的。有社区范畴的个别角色，以及特定于组和我的项目的角色。
理事会治理社区的构造和运作，依据序言中规定的准则监控社区的衰弱。它保持并保护这些章程，解决程序纠纷，并确保有足够的根底构造可用。理事会对技术或公布决策没有间接势力。
1. 角色定义
Participant（参与者）
参与者是订阅了一个或多个 OpenJDK 邮件列表的集体。参与者能够将音讯公布到列表中，提交简略的补丁，以及做出其余类型的小奉献。
Contributor（贡献者）
贡献者是签订了甲骨文贡献者协定 (Oracle Contributor Agreement，OCA) 的参与者，或者为签订了该协定或等同协定的组织工作，并在该工作范畴内依据该协定做出奉献。贡献者能够提交比一个简略的补丁更大的更改，能够提出新的我的项目，能够在组和我的项目中负责不同的角色。
如果贡献者的待业状况产生了变动，使得贡献者不再被 OCA 或其等同产品笼罩，那么贡献者必须告诉 OpenJDK * 管，从而放弃这个角色。
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 这是一个 OpenJDK 成员，由 Oracle 任命，他领导社区的 要工作，这些工作是 Java SE 平台的新实现，称为 JDK Release Projects。OpenJDK 管负责这些我的项目中应用的开发过程的公开性和透明性，并且还能够解决某些类型的程序纠纷。OpenJDK 管是理事会成员。
2.Governing Board（GB，理事会）
Governing Board (GB，理事会)治理 OpenJDK Community 的构造和操作。
JDK Release Projects 是 Java SE 平台实现的新版本我的项目。此类我的项目只能由 OpenJDK 管提议，并且只能由 GB 资助。OpenJDK 管是所有 JDK Release Projects 的我的项目负责人。每个 OpenJDK 成员都有机会提出要 含在 JDK Release Projects 中的个性，并且对于要 含哪些个性的决定将以通明的形式做出。
GB 构造
GB 由五个出资人组成：
**，由 Oracle 任命；
副 **，由 IBM 任命；
OpenJDK * 管由 Oracle 任命；
两名一般成员，由 OpenJDK 成员提名和选举。
GB 一般成员
GB 的一般成员由 OpenJDK 成员投票选出。一般成员的任期为一个日历年，从每年的 4 月 1 日开始。
在为期两周的提名期内，任何 OpenJDK 成员都能够提名目前没有被任命 GB 理事 位的集体来填补一个一般成员 位。该集体不用曾经是 OpenJDK 成员。OpenJDK 成员能够做出多个这样的提名。
GB 职责
GB 在某种程度上是一个立法机构：它有权订正这些章程，以欠缺现有流程，定义新流程以及处理不再须要的流程。对这些章程的任何订正都必须取得理事会相对三分之二多数票（赞成票至多是否票的两倍，且总票数至多有三张票）的批准，而后由 OpenJDK 成员的三分之二批准。
GB 在某种程度上也是司法机构：它有权解决独特体内可能产生的任何程序性纠纷。如本细则所述，集体做出的任何程序性决定均可向 GB 提出上诉。如果 GB 决定听取上诉，则提议的裁决必须经简略少数投票批准。
GB 不是一个执行机构：它对技术或公布决定没有间接的势力。对于任何给定的我的项目，该权限由该项目标负责人持有（特地 OpenJDK 领导的 JDK Release Projects）。
GB 是一个小组，由 * 持。这使 GB 能够资助我的项目。遣散组，增加和删除组成员以及抉择和删除组负责人的通常规定不适用于 GB。
GB 不得少于五个人。它应始终 括，副 ，OpenJDK 管和至多两个如上所述的一般成员 * 位。
GB 能够以相对多数票投票通过，增补或吊销任命的和一般成员的 GB * 位。
GB 能够通过投票邀请特定集体作为观察员加入 GB 会议。这样的人不用是 OpenJDK 成员。咱们欢送观察员聆听并为对话做奉献，但他们没有任何投票权。GB 可通过投票罢免观察员。
如果 GB 成员真诚地拥护 OpenJDK * 管做出的技术或公布决定，能够提出上诉。
GB 应答所有社区个人和我的项目进行年度审查，以打消被确定为有效的任何此类流动。
4.Java Community Process（JCP，Java 社区过程）
Java Community Process（JCP）成立于 1998 年，是一种正式的机制，容许感兴趣的各方开发 Java 的规范技术规范。只有填写 JCP 网站上的表格，任何人都能够成为 JCP 会员。组织和商业实体的 JCP 成员资格须要年费，但集体收费。
JCP 是国内 Java 社区标准化和批准 Java 技术规范的过程。JCP 确保应用基于共识的 * 容性办法来开发高质量的标准。JCP 批准的标准必须随附参考实现（以证实能够实现标准）和技术兼容性套件（用于测试实现是否符合规范的一套测试，工具和文档）。
任何 Java 技术的加强或新技术的引入都通过 Java Specification Request（JSR）进行。
1. 角色定义
Observer（观察者）
集体无需签订正式的 JCP 成员协定即可察看和评论专家组的流动，因为他们能够利用 JCP 的透明度机制，例如公共邮件列表和问题跟踪工具。
无关如何提供反馈的信息能够在 JSR 的合作我的项目页面上找到（在 jcp.org 的 JSR 页面上提供了指向该页面的指针）。观察者没有资格加入专家组，竞选 EC 委员或加入 JCP 的年度选举。
Associate Member（准成员）
不违心或无奈签订 JSPA 的集体能够签订准成员协定以加入 JCP 的流动。（组织不合乎此类成员资格。）准成员协定比 JSPA 更简略，并且仅波及集体 IP 承诺。无需雇 * 签名。
准成员不能负责特地负责人，不能退出专家组或竞选 EC 委员。他们有资格投票的 EC 的准 位，但没有资格投票批准或选举 位。依据 Spec leader 的酌情决定权，准成员能够被列为 JSR 的贡献者，从而失去正式认可。
Partner Member（合作伙伴成员）
不违心或无奈（因为它们不是非法实体）签订 JSPA 的非营利组织（例如 Java 用户组）能够签订简化的合作伙伴成员协定，该协定的重点是与 JCP 成员和 PMO 单干促成 JCP 流动。
合作伙伴成员不能负责标准负责人或不能在大多数专家组中任职，但有资格竞选 EC 委员。如果被选出，则能够作为 EC 委员来负责 JSR 专家组的成员，这些专家组的重点是从新定义 JCP 的组织和“宪法”。合作伙伴成员具备与正式会员雷同的投票权。
Full Member（正式成员）
这类成员是凋谢的公司，非营利组织的法人实体，个体户和就业的集体，学生和一些受雇的集体。JSPA 是正式成员的成员协定。如果非待业集体和大学教职人员可能非法受权他们本人的知识产权，并因而可能代表本人签订 JSPA，那么他们就有资格成为正式成员。雇 如违心签订雇 供款协定 (大学职员无需签订雇 供款协定)，雇员便可成为正式成员。这些集体应应用其雇员电子邮件地址而不是集体电子邮件地址进行注册，以便 PMO 可能跟踪待业情况的变动。他们还应批准在更换雇 时告诉 PMO。
正式成员能够充当标准负责人，退出专家组，并竞选 EC 的任何级别的 位。正式成员可投票选举 EC 的批准和选举 位，但不得投票选举准 * 位。
Member Representative（成员代表）
与正式成员有合同关系的雇员和其余集体能够被正式成员受权在 JCP 中代表其利益，作为 Spec leader，在专家组服务，或竞选 EC。这些成员应以其雇员电邮地址而非集体电邮地址注销，以便 PMO 能追踪雇员的变动。他们还应批准在更换雇 * 时告诉 PMO。
2.Executive Committee（EC，执行委员会）
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 个。
EC 的 * 位构造和任期工夫
永恒 * 位 —1 个 — 由 Oracle 领有；
批准 * 位 —11 个；
选举 * 位 —4 个；
准 * 位 —2 个；
委员的任期为 2 年，任期错开，所以 17 个 位中每年都有一半的 位能够选举。
批准 * 位选举过程
在适当思考到均衡的社区和区域代表性的状况下，PMO 提名成员填补空缺的批准 * 位。
正式成员和合作伙伴成员将投票表决，在 14 天的投票期内批准每位被提名人。
被提名者失去投票人的简略少数批准(赞成比拥护多)。
如果一个或多个被提名人未经表决取得批准，PMO 应视须要提名额定成员，并举办额定的批准投票，直至空缺 * 位失去填补。
选举 位和准 位选举过程
投票前六周，PMO 应在 JCP 公开选举投票站上张贴对候选人将在选举期间提供的所有资料（候选人申明，立场文件等）的残缺形容。同时，PMO 将发表承受提名的工夫至多为 14 天。
正式成员和合作伙伴成员能够提名本人竞选这些 位。被提名者必须具体阐明他们是在提名本人竞选选举 位还是准 * 位。
JCP 成员的雇员不能自行竞选，PMO 将回绝此类提名。
提名期完结后，PMO 将公布所有被提名人的姓名。
在投票期间，议员能够投票给与空缺 位一样多的被提名人。（正式成员和合作伙伴成员可投票选举选举 位；准会员可投票选举准 * 位。）
得票最多的提名人应填补空缺 * 位。
如果只有一个空缺的提名人，则应给予选民投票的机会？或没有？对于那个候选人。入选的候选人必须取得简略少数。
如果没有候选人填补空缺，EC 可抉择保留这个空缺，直至下一次选举。
目前 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, 选举 * 位
5.Java Specification Request（JSR, Java 标准申请）
Java Specification Request（JSR）是一个正式的、凋谢的对 Java 平台的倡议和最终标准的理论形容，由集体或组织向 Java Community Process（JCP）提出。它 * 含对 Java 技术平台的倡议更改，增加或改良。
1.JSR 草案发动
发动 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 中承受和执行。
为了防止出现碎片，新的平台版本标准不得实质性地复制现有平台版本或概要文件。
配置文件和 API 标准以以后平台版本为指标
所有新的或订正的标准必须与指标平台版本标准的最新版本兼容。为了实现此目标，所有定义新的概要文件标准或订正现有概要文件标准必须参考其所基于的平台版本标准的最新版本，或者援用正在通过流动 JSR 开发的该标准的更新版本。
平台 * 含
须要 JSR 提交来阐明 JSR 的 RI 和 TCK 是作为概要文件还是平台版本的一部分，以独立形式或两者同时提供。对于特定 JSR 是否 含在概要文件或平台版本中的最终决定由概要文件或平台版本 JSR 的标准负责人和专家组做出的相干 JSR 的 EC 选票确认。如果概要文件或平台版本的标准 管回绝了 * 含申请，则 JSR 必须提供独立的 RI 和 TCK。
在最后独立交付后，能够将技术合并到概要文件或平台版本中。提议成为概要文件或平台版本的一部分并思考进行独立可用性的新版 API 的 JSR 必须阐明进行此更改的理由，并且必须告知公众要终止独立 RI 的用意，并且 TCK 提前公布了一个 JSR。
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 批准投票和专家组的造成
在 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 可能遵循维护阶段流程。
2. 公布 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 是对现有标准的订正，则标准负责人应复原以后标准的保护负责人的角色。
如果专家组认为这会有所帮忙，则能够进行屡次公开草案和审核。
3.JSR 定案
实现规格
如果公众审查最初批准投票 (或复议投票) 胜利，专家组应通过实现其认为对意见作出必要批改的形式编制最终标准草案。
实现 RI 和 TCK
标准负责人负责实现 RI 和 TCK。须要针对多个平台的 JSR 来反对每个环境，这可能须要为每个环境提供独自的 RI 和 TCK。如果 RI 和 TCK 发现标准中定义有余、不残缺或不置可否的中央，标准负责人应与专家组单干纠正这些缺点，而后将订正后的标准连同变更摘要一起发送给 PMO。信息应公布在 JCP 网站上。专家组应持续审议在此期间收到的任何进一步意见。
建设高级 TCK 申述流程
标准负责人还负责建设一个明确定义的一级 TCK 申述程序，以应答 TCK 中 * 含的测试挑战。此过程必须在 TCK 文档中形容。对高级决策不称心的实施者应通过向 PMO 发送电子邮件，记录他们的担心，向 EC 申述。PMO 将把申请连同从管理层收到的对于高级决定理由的任何信息一起分发给 EC，并发动为期 7 天的申述投票。
依据 TCK 上诉更新可交付成绩
依据问题的性质，一个胜利的 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 自身或相干的保护版本将被标记为已撤回。
6.* 流 OpenJDK builds
Build
LTS
宽松式许可证
通过 TCK 测试
未修改上游的构建
提供商业反对
AdoptOpenJDK
Yes
Yes
No
可选
可选(IBM)
Alibaba Dragonwell
Yes
Yes
Yes
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
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
Oracle Java SE
Yes
No
Yes
No
Yes
Oracle OpenJDK
No
Yes
Yes
Yes
No
Red Hat build of OpenJDK
Yes
Yes
Yes
No
Yes
Tencent Kona
Yes
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 的官网参考实现，只产生 OpenJDK 源码，并不提供能够间接应用的二进制文件格式。当初能间接应用的二进制文件格式的 JDK 都是被编译之后的程序。
自 Java SE 7 开始往后的版本，所有的 JDK 都源自于 Open JDK(OpenJDK 与 其余 JDK 的关系就和 Linux 与它的泛滥发行版是一样一样的)。所以严格意义上来说 Oracle JDK 也是 Open JDK 的一个发行版而已。
* 流 OpenJDK builds 中暂未通过 TCK 的 build
AdoptOpenJDK
截止 2021 年 5 月 8 日，AdoptOpenJDK 官网的申明：
Java Compatibility Kit (JCK) / TCK ComplianceAt this stage the London Jamocha Community CIC (aka LJC) has not been able to reach an agreement with Oracle to use the Java SE Technology Compatibility Kit (TCK) under the terms of the OpenJDK Community TCK License Agreement (OCTLA).We will continue to work with Oracle on this matter.All AdoptOpenJDK binaries are tested with our suite of functional, integration, stress, and performance tests, including real workloads from popular languages and applications. We are very confident in the quality of our builds.
ojdkbuild
截止 2021 年 5 月 8 日，ojdkbuild 的 GitHub README.md 中 FAQ 的阐明：
Question 2:Q: Is this project endorsed by upstream OpenJDK project?A: No.Question 3:Q: Will any questions about the TCK be answered (regarding this project)?A: No.
Technology Compatibility Kit (TCK，技术兼容工具 *)
依据 OpenJDK 的 Gaining Access to the JCK 的形容：
Gaining Access to the JCKThe Java Compatibility Kit (a.k.a., the JCK or TCK for Java SE) is available at no charge to developers who are planning to deploy a compatible Java implementation based on code derived from OpenJDK, or are participating in OpenJDK research, bug fixes, code enhancement and/or ports to other hardware/software architectures.The JCK is made available under the terms of the OpenJDK Community TCK License Agreement (OCTLA). The current version of the OCTLA is for Java SE 9 or later (OCTLA JDK 9 V 3.0). Please contact oracle-ca_us [at] oracle [dot] com with any questions.The signatories of past and present versions of the OCTLA are listed here.ProcessTo obtain access to the JCK, please follow this process:
Review the terms of the OCTLA License.Fill out and submit the JCK access request form.The screening committee will review your form and determine if your application meets the requirements for JCK access.After Oracle reviews your application, you will be notified via e-mail of the decision of the screening committee.If you are granted access, you will need to send a signed copy of the OCTLA License to Oracle. The signed form can be scanned and e-mailed to oracle-ca_us [at] oracle [dot] com.If you have not signed the Oracle Contributor Agreement (OCA), then please do so, scan it and e-mail the result to oracle-ca_us [at] oracle [dot] com.Once Oracle receives your signed faxes, you will receive an e-mail explaining how to download the JCK.
Requirements for JCK access
Your project must be active and meet the terms of the OCTLA.Your project can be inside or outside the OpenJDK community, but you must sign the OCA.
Note: Signing the OCA does not require that you provide any code back to Oracle or OpenJDK, however, it is mutually beneficial to all parties if relevant patches are shared throughout the OpenJDK community. Signing the OCA makes it possible for you to contribute your patches to OpenJDK.SupportSupport for the JCK will be limited and handled primarily through a private mailing list shared by Oracle and all OCTLA licensees. If you are planning to do a wide distribution of compatible implementations and are interested in branding, other services may also be made available through Oracle’s licensee support organization.If you have any questions for Oracle regarding your request for JCK access, please e-mail oracle-ca_us [at] oracle [dot] com.
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 的官网参考实现，只产生 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 开发规范的 JSR 是泛滥由 JCP 成员发动的 JSR 草案在通过：JSR 草案发动、JCP 公众评审、JSR 最终定案、JCP 的 EC 评审等步骤后，胜利诞生的 JSR 聚合而成的。
上面用一张图简略概括本篇文章的要点：
因为本篇文章内容太长，OpenJDK builds 与 OracleJDK 的抉择问题就留到下一章独自开一篇专门来写（不过我想认真看完这一章的敌人，应该曾经分明晓得了他们的区别以及什么状况下应抉择哪个版本了吧）。
以上就是《OpenJDK》的分享。
也欢送大家交换探讨，该文章若有不正确的中央，心愿大家多多包涵。
你们的反对就是我最大的能源，如果对大家有帮忙给个赞哦~~~