java中的OpenJDK是什么

這篇文章主要介紹“java中的OpenJDK是什么”，在日常操作中，相信很多人在java中的OpenJDK是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”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 產出的 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 的開源地址

2.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版本的基礎上提供更新。

3.OpenJDK Community（OpenJDK 社區）

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 的委員以及任期

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

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 的一個發行版而已。

主流 OpenJDK builds 中暫未通過 TCK 的 build

AdoptOpenJDK

截止2021年5月8日，AdoptOpenJDK 官網的聲明：

ojdkbuild

截止2021年5月8日，ojdkbuild 的 GitHub README.md 中 FAQ 的說明：

Technology Compatibility Kit (TCK，技術兼容工具包)

根據 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是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！