java中的OpenJDK是什么

這篇文章主要介紹“java中的OpenJDK是什么”，在日常操作中，相信很多人在java中的OpenJDK是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”java中的OpenJDK是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：域名注冊、雅安服務器托管、營銷軟件、網(wǎng)站建設、黃驊網(wǎng)站維護、網(wǎng)站推廣。

1.OpenJDK 概述

OpenJDK 是 Java 平臺標準版 (Java SE) 的免費開源實現(xiàn)。這是 Sun Microsystems (以下簡稱：Sun) 于2006年開始努力的結(jié)果。該實現(xiàn)已獲得 GNU通用公共許可證（GNU GPL）版本2的許可。但有鏈接例外。除 GPL 特例鏈接之外，鏈接到 Java 類庫的組件將受到 GPL 許可條款的約束。

OpenJDK Project 產(chǎn)生了許多組件：最重要的是虛擬機( HotSpot )，Java類庫和Java編譯器( javac )。

從 Java SE 7 開始，OpenJDK Project 產(chǎn)出的 OpenJDK 成為了 Java SE 的官方參考實現(xiàn)。

從 Java SE 10 開始，JDK Project（ OpenJDK Community 的下屬項目） 產(chǎn)出的 OpenJDK 成為了 Java SE 的官方參考實現(xiàn)。

沒錯，從 Java SE 7開始往后的版本，連大名鼎鼎的 Oracle JDK 都是根據(jù) Open JDK 做出來的(修改了一些功能的實現(xiàn)方式，再打上自己的商標并提供配套服務)。或者應該說自 Java SE 7開始往后的版本，所有的 JDK 都源自于 Open JDK(OpenJDK 與 其他 JDK 的關(guān)系就和 Linux 與它的眾多發(fā)行版是一樣一樣的)。

OpenJDK 是由 OpenJDK Community 、Oracle、IBM 領(lǐng)導，連同 Alibaba，Amazon，Ampere，Azul，BellSoft，Canonical，F(xiàn)ujitsu，Google，Huawei，Intel，Java Community，JetBrains，London Java Community，Microsoft，Red Hat，SAP，SouJava，SUSE，Tencent，Twitter ，VMWare 等第三方共同開發(fā)、維護的 Java SE 開源參考實現(xiàn)。

OpenJDK 具體版本的開發(fā)標準是 Java Community Process（JCP，Java 社區(qū)進程） 發(fā)布的  Java Specification Requests（JSR，Java規(guī)范請求）。

OpenJDK Community 領(lǐng)導的 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）產(chǎn)出的 OpenJDK 是 Java SE 的官方參考實現(xiàn)，只產(chǎn)生 OpenJDK 源碼，并不提供可以直接使用的二進制文件格式。現(xiàn)在能直接使用的二進制文件格式的 JDK 都是被編譯之后的程序。OpenJDK 官網(wǎng)指向的可下載二進制文件的地址，實際是 Oracle’s OpenJDK builds 下載的地址。沒錯，這也是被 Oracle 編譯后的版本。

OpenJDK 使用 Git 在GitHub 的開源地址，OpenJDK 使用 Mercurial 在 OpenJDK 的開源地址

2.OpenJDK 的發(fā)展史

1995年5月23日，Sun 公司在 Sun world 會議上正式發(fā)布 Java。

1996年1月23日，Sun 公司發(fā)布了 Java 的第一個開發(fā)工具包。

Sun 在 JavaOne 2006 中宣布 Java 將成為開源軟件并建立了 Open JDK 社區(qū)。

2006年11月13日 Sun 根據(jù) GNU 通用公共許可證 將 Java HotSpot 虛擬機和編譯器作為免費軟件發(fā)布，并承諾將在2007年3月之前將其余的 JDK（包括Java運行時環(huán)境）置于 GPL 之下。

Sun 承諾在2007年上半年發(fā)布幾乎完全基于免費和開源代碼的 Java 開發(fā)工具包（JDK）。

2007年5月8日 Sun 在 GPL 下發(fā)布了 Java 類庫的完整源代碼。

2007年，除了一些被第三方授權(quán)給 Sun 且 Sun 無法根據(jù) GPL 重新授權(quán)的受限部分之外，被限制的部分列表中還包括 Java 圖形用戶界面（GUI）的幾個主要組件。Sun 表示計劃用替代的實現(xiàn)方式替換其余的私有組件，并使類庫完全免費。

在最初2007年5月發(fā)布時，OpenJDK 類庫仍然有4％是私有的。到2008年5月OpenJDK 6出現(xiàn)時，只剩下不到1％（SNMP 實現(xiàn)，它不是 Java 規(guī)范的一部分）是私有的，使得無需任何二進制插件即可構(gòu)建 OpenJDK。二進制插件要求后來在2009年4月將 b53 從 OpenJDK 7 中刪除。

OpenJDK 6 Project，基于JDK 7，但經(jīng)過修改(刪除 Java 7 的特性)后提供了Java 6的開源版本。

OpenJDK 7 Project，于2011年7月28日發(fā)布GA(General Availability，一般可用性)版本。 OpenJDK 7 Update Releases Project，該項目在 OpenJDK 7 初代GA版本的基礎上提供更新。

OpenJDK 8 Project，于2014年3月18日發(fā)布GA版本。 OpenJDK 8 Update Releases Project，該項目在 OpenJDK 8 初代GA版本的基礎上提供更新。

OpenJDK 9 Project，于2017年9月21日發(fā)布GA版本。

JDK Project（ OpenJDK Community 下屬項目）： (這個長期運行的項目的目標是生成一系列 Java SE 平臺的開源參考實現(xiàn)，正如 Java Community Process 中的 JSR 所指定的那樣。根據(jù)一個嚴格的、基于時間的模型，該項目每六個月發(fā)布一個特性版本） OpenJDK 10，于2018年3月20日發(fā)布GA版本。 OpenJDK 11，于2018年9月25日發(fā)布GA版本。 OpenJDK 12，于2019年3月19日發(fā)布GA版本。 OpenJDK 13，于2019年9月17日發(fā)布GA版本。 OpenJDK 14，于2020年3月17日發(fā)布GA版本。 OpenJDK 15，于2020年9月15日發(fā)布GA版本。 OpenJDK 16，于2021年3月16日發(fā)布GA版本。 OpenJDK 17，目前正在開發(fā)中，預計于2021年9月14日發(fā)布GA版本。

JDK Update Releases Project（ OpenJDK Community 下屬項目）： (該項目的目標是為 JDK Project 開發(fā)更新） 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 社區(qū)）

OpenJDK Community 是一個開發(fā)人員協(xié)會，他們在 Java Community Process 定義的Java平臺標準版（Java SE）的當前版本和未來版本的開源實現(xiàn)以及密切相關(guān)的項目上進行協(xié)作。這些規(guī)章制度的目標是通過允許和鼓勵社區(qū)成員以公開、透明和精英的方式行事，促進社區(qū)的長期健康和發(fā)展。

OpenJDK Community 由一組團體和一組項目組成，這些團體是一組就共同興趣進行公開對話的個人的集合，而這些項目是共同努力以產(chǎn)生特定工件的。 有社區(qū)范圍的一般角色，以及特定于組和項目的角色。

理事會管理社區(qū)的結(jié)構(gòu)和運作，根據(jù)序言中規(guī)定的原則監(jiān)控社區(qū)的健康。 它堅持并維護這些章程，解決程序糾紛，并確保有足夠的基礎結(jié)構(gòu)可用。 理事會對技術(shù)或發(fā)布決策沒有直接權(quán)力。

1.角色定義

Participant（參與者）

參與者是訂閱了一個或多個 OpenJDK 郵件列表的個人。參與者可以將消息發(fā)布到列表中，提交簡單的補丁，以及做出其他類型的小貢獻。

Contributor（貢獻者）

貢獻者是簽署了甲骨文貢獻者協(xié)議 (Oracle Contributor Agreement，OCA) 的參與者，或者為簽署了該協(xié)議或同等協(xié)議的組織工作，并在該工作范圍內(nèi)根據(jù)該協(xié)議做出貢獻。貢獻者可以提交比一個簡單的補丁更大的更改，可以提出新的項目，可以在組和項目中擔任不同的角色。

如果貢獻者的就業(yè)情況發(fā)生了變化，使得貢獻者不再被OCA或其同等產(chǎn)品覆蓋，那么貢獻者必須通知 OpenJDK 主管，從而放棄這個角色。

OpenJDK 成員

任何集團成員或提交者都可被現(xiàn)有的 OpenJDK 成員提名為 OpenJDK 的成員。這樣的提名必須得到 OpenJDK 成員至少三票同意。

任何 OpenJDK 成員都可以提出刪除另一個 OpenJDK 成員的動議。這樣的動議必須由 OpenJDK 成員的三分之二多數(shù)票（贊成票至少是否票的兩倍）批準，而作為動議主題的成員棄權(quán)。

在特殊情況下，理事會可以以三分之二多數(shù)票（贊成票至少是否票的兩倍）罷免 OpenJDK 成員。

每一個 OpenJDK 成員資格在一年后會自動到期，但會根據(jù)要求續(xù)訂。續(xù)展申請必須在期滿一年內(nèi)收到。除非需要 OpenJDK 成員資格的角色可以保留，否則成員資格已過期且尚未續(xù)期的 OpenJDK 成員不能行使成員資格特權(quán)。

如果一個 OpenJDK 成員的就業(yè)情況發(fā)生了變化，這樣的貢獻將不再被 OCA 或它的同等物覆蓋，那么成員必須通過通知 OpenJDK 主管放棄貢獻者角色。此時，成員資格將被視為已過期。

The OpenJDK Members Group 由所有 OpenJDK 成員組成。OpenJDK 負責人是其組織的負責人。解散組，添加和刪除組成員以及選擇和刪除組負責人的通常規(guī)則不適用于 OpenJDK Members Group 。

OpenJDK 主管

OpenJDK 主管是一個 OpenJDK 成員，由 Oracle 任命，他指導社區(qū)的主要工作，這些工作是 Java SE 平臺的新實現(xiàn)，稱為 JDK Release Projects。OpenJDK 主管負責這些項目中使用的開發(fā)過程的公開性和透明性，并且還可以解決某些類型的程序糾紛。OpenJDK 主管是理事會成員。

2.Governing Board （GB，理事會）

Governing Board (GB，理事會)管理 OpenJDK Community 的結(jié)構(gòu)和操作。

JDK Release Projects 是Java SE平臺實現(xiàn)的新版本項目。此類項目只能由 OpenJDK 主管提議，并且只能由 GB 贊助。OpenJDK 主管是所有 JDK Release Projects 的項目負責人。每個 OpenJDK 成員都有機會提出要包含在 JDK Release Projects 中的特性，并且關(guān)于要包含哪些特性的決定將以透明的方式做出。

GB 結(jié)構(gòu)

GB 由五個出資人組成：

• 主席，由Oracle任命；

• 副主席，由IBM任命；

• OpenJDK 主管由Oracle任命；

• 兩名普通成員，由 OpenJDK 成員提名和選舉。

GB 普通成員

GB 的普通成員由 OpenJDK 成員投票選出。普通成員的任期為一個日歷年，從每年的4月1日開始。

在為期兩周的提名期內(nèi)，任何 OpenJDK 成員都可以提名目前沒有被任命 GB 理事席位的個人來填補一個普通成員席位。該個人不必已經(jīng)是 OpenJDK 成員。OpenJDK 成員可以做出多個這樣的提名。

GB 職責

GB 在某種程度上是一個立法機構(gòu)：它有權(quán)修訂這些章程，以完善現(xiàn)有流程，定義新流程以及處置不再需要的流程。對這些章程的任何修訂都必須獲得理事會絕對三分之二多數(shù)票（贊成票至少是否票的兩倍，且總票數(shù)至少有三張票）的批準，然后由 OpenJDK 成員的三分之二批準。

GB 在某種程度上也是司法機構(gòu)：它有權(quán)解決共同體內(nèi)可能發(fā)生的任何程序性糾紛。如本細則所述，個人做出的任何程序性決定均可向 GB 提出上訴。如果 GB 決定聽取上訴，則提議的判決必須經(jīng)簡單多數(shù)投票批準。

GB 不是一個執(zhí)行機構(gòu)：它對技術(shù)或發(fā)布決定沒有直接的權(quán)力。對于任何給定的項目，該權(quán)限由該項目的負責人持有（特別 OpenJDK 領(lǐng)導的 JDK Release Projects）。

GB 是一個小組，由主席主持。這使 GB 可以贊助項目。解散組，添加和刪除組成員以及選擇和刪除組負責人的通常規(guī)則不適用于 GB。

GB 不得少于五個人。 它應始終包括主席，副主席，OpenJDK 主管和至少兩個如上所述的普通成員席位。

GB 可以以絕對多數(shù)票投票通過，增補或撤消任命的和普通成員的 GB 席位。

GB 可以通過投票邀請?zhí)囟▊€人作為觀察員參加 GB 會議 。這樣的人不必是 OpenJDK 成員。我們歡迎觀察員傾聽并為對話做貢獻，但他們沒有任何投票權(quán)。GB 可通過投票罷免觀察員。

如果 GB 成員真誠地反對 OpenJDK 主管做出的技術(shù)或發(fā)布決定，可以提出上訴。

GB 應對所有社區(qū)團體和項目進行年度審查，以消除被確定為無效的任何此類活動。

4.Java Community Process（JCP，Java 社區(qū)進程）

Java Community Process（JCP）成立于1998年，是一種正式的機制，允許感興趣的各方開發(fā)Java的標準技術(shù)規(guī)范。 只要填寫JCP網(wǎng)站上的表格，任何人都可以成為JCP會員。 組織和商業(yè)實體的JCP成員資格需要年費，但個人免費。

JCP 是國際 Java 社區(qū)標準化和批準 Java 技術(shù)規(guī)范的過程。JCP 確保使用基于共識的包容性方法來開發(fā)高質(zhì)量的規(guī)范。JCP 批準的規(guī)范必須隨附參考實現(xiàn)（以證明可以實現(xiàn)規(guī)范）和技術(shù)兼容性套件（用于測試實現(xiàn)是否符合規(guī)范的一套測試，工具和文檔）。

任何 Java 技術(shù)的增強或新技術(shù)的引入都通過 Java Specification Request （JSR）進行。

1.角色定義

Observer（觀察者）

個人無需簽署正式的 JCP 成員協(xié)議即可觀察和評論專家組的活動，因為他們可以利用 JCP 的透明度機制，例如公共郵件列表和問題跟蹤工具。

有關(guān)如何提供反饋的信息可以在 JSR 的協(xié)作項目頁面上找到（在 jcp.org 的 JSR 頁面上提供了指向該頁面的指針）。觀察者沒有資格參加專家組，競選 EC 委員或參加 JCP 的年度選舉。

Associate Member（準成員）

不愿意或無法簽署 JSPA 的個人可以簽署準成員協(xié)議以參加 JCP 的活動。（組織不符合此類成員資格。）準成員協(xié)議比 JSPA 更簡單，并且僅涉及個人IP承諾。無需雇主簽名。

準成員不能擔任特別負責人，不能加入專家組或競選 EC 委員。他們有資格投票的 EC 的準席位，但沒有資格投票批準或選舉席位。根據(jù) Spec leader 的酌情決定權(quán)，準成員可以被列為 JSR 的貢獻者，從而得到正式認可。

Partner Member（合作伙伴成員）

不愿意或無法（因為它們不是合法實體）簽署 JSPA 的非營利組織（例如 Java 用戶組）可以簽署簡化的合作伙伴成員協(xié)議，該協(xié)議的重點是與 JCP 成員和 PMO 合作促進 JCP 活動。

合作伙伴成員不能擔任規(guī)范負責人或不能在大多數(shù)專家組中任職，但有資格競選 EC 委員。如果被選出，則可以作為 EC 委員來擔任 JSR 專家組的成員，這些專家組的重點是重新定義 JCP 的組織和“憲法”。合作伙伴成員具有與正式會員相同的投票權(quán)。

Full Member（正式成員）

這類成員是開放的公司，非營利組織的法人實體，個體戶和失業(yè)的個人，學生和一些受雇的個人。JSPA 是正式成員的成員協(xié)議。如果非就業(yè)個人和大學教職人員能夠合法授權(quán)他們自己的知識產(chǎn)權(quán)，并因此能夠代表自己簽署 JSPA，那么他們就有資格成為正式成員。雇主如愿意簽署雇主供款協(xié)議(大學職員無需簽署雇主供款協(xié)議)，雇員便可成為正式成員。這些個人應使用其雇員電子郵件地址而不是個人電子郵件地址進行注冊，以便 PMO 能夠跟蹤就業(yè)狀況的變化。他們還應同意在更換雇主時通知 PMO。

正式成員可以充當規(guī)范負責人，加入專家組，并競選 EC 的任何級別的席位。正式成員可投票選舉 EC 的批準和選舉席位，但不得投票選舉準席位。

Member Representative（成員代表）

與正式成員有合同關(guān)系的雇員和其他個人可以被正式成員授權(quán)在JCP中代表其利益，作為 Spec leader，在專家組服務，或競選 EC。這些成員應以其雇員電郵地址而非個人電郵地址登記，以便 PMO 能追蹤雇員的變動。他們還應同意在更換雇主時通知 PMO。

2.Executive Committee（EC，執(zhí)行委員會）

Executive Committee (EC，執(zhí)行委員會)是在 JCP 中指導 Java 技術(shù)發(fā)展的成員組。EC 既代表主要利益相關(guān)者，又代表 Java Community 的代表性部門，監(jiān)督 JCP 內(nèi) Java 技術(shù)的發(fā)展和演變。

EC 負責選擇要在 JCP 中進行開發(fā)的 JSR，批準規(guī)范草案供公眾審查，并協(xié)調(diào)規(guī)范及其相關(guān)測試套件之間的差異，對完成的規(guī)范及其相關(guān)的 RI 和 TCK 給予最終批準，審查和批準維護版本，對第一階段的 TCK 測試申訴做出決定，批準成員之間的維修職責轉(zhuǎn)移，為 PMO 和 JCP Community 提供指導。

EC 委員必須分析、評論、投票，并決定批準提交給該計劃的所有 JSR。除了負責指導整個平臺的演變外，EC 和整個 JCP 計劃還負責 JCP 計劃本身，使它遵守社區(qū)對該計劃及其成員的期望。

根據(jù) JCP Process Document 2.11.10（2019年7月21日）的規(guī)定在2020年的年度選舉中，兩個批準的席位和一個選舉席位將被取消，從而將 EC 的委員席位減少到18個。

EC 的席位結(jié)構(gòu)和任期時間

• 永久席位---1個---由 Oracle 擁有；

• 批準席位---11個；

• 選舉席位---4個；

• 準席位---2個；

委員的任期為2年，任期錯開，所以17個席位中每年都有一半的席位可以選舉。

批準席位選舉過程

• 在適當考慮到平衡的社區(qū)和區(qū)域代表性的情況下，PMO 提名成員填補空缺的批準席位。

• 正式成員和合作伙伴成員將投票表決，在14天的投票期內(nèi)批準每位被提名人。

• 被提名者得到投票人的簡單多數(shù)批準(贊成比反對多)。

• 如果一個或多個被提名人未經(jīng)表決獲得批準，PMO 應視需要提名額外成員，并舉行額外的批準投票，直至空缺席位得到填補。

選舉席位和準席位選舉過程

• 投票前六周，PMO 應在 JCP 公開選舉投票站上張貼對候選人將在選舉期間提供的所有材料（候選人聲明，立場文件等）的完整描述。同時，PMO 將宣布接受提名的時間至少為14天。

• 正式成員和合作伙伴成員可以提名自己競選這些席位。被提名者必須具體說明他們是在提名自己競選選舉席位還是準席位。

• JCP 成員的雇員不能自行競選，PMO 將拒絕此類提名。

• 提名期結(jié)束后，PMO 將發(fā)布所有被提名人的姓名。

• 在投票期間，議員可以投票給與空缺席位一樣多的被提名人。（正式成員和合作伙伴成員可投票選舉選舉席位；準會員可投票選舉準席位。）

• 得票最多的提名人應填補空缺席位。

• 如果只有一個空缺的提名人，則應給予選民投票的機會？或沒有？對于那個候選人。當選的候選人必須獲得簡單多數(shù)。

• 如果沒有候選人填補空缺，EC 可選擇保留這個空缺，直至下一次選舉。

目前 EC 的委員以及任期

委員	任期結(jié)束
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, 選舉席位
Twitter	2021, 選舉席位

5.Java Specification Request（ JSR, Java 規(guī)范請求）

Java Specification Request （JSR）是一個正式的、開放的對Java平臺的建議和最終規(guī)范的實際描述，由個人或組織向Java Community Process（JCP）提出。它包含對Java技術(shù)平臺的建議更改，添加或改進。

1.JSR草案發(fā)起

發(fā)起Java規(guī)范請求

一個或多個正式成員可以通過 JCP 網(wǎng)站提交 JSR 提案，以發(fā)起制定新規(guī)范或?qū)ΜF(xiàn)有規(guī)范進行重大修訂的請求。

每個 JSR 必須提供以下信息：

• 提出請求的成員（提交者），擬議的規(guī)范負責人，專家組的初始成員以及潛在貢獻者的姓名；

• 擬議規(guī)范的描述；

• 開發(fā)或修改它的原因；

• 主要平臺版本，以及對其他平臺版本的任何考慮；

• 預計的開發(fā)進度；

• 任何可以作為起點的現(xiàn)有文檔、技術(shù)描述或?qū)崿F(xiàn)；

• 一個透明性計劃，它概述了規(guī)范負責人在開發(fā)規(guī)范期間將使用的工具和技術(shù)，以便與 JCP 成員和公眾進行溝通，并尋求反饋。

• JSR 是否是迭代的，如果是，則預期的迭代周期。

由 PMO 酌情決定，可能要求 JSR 提交的內(nèi)容包括完整的 JSR 審查流程問卷或演示文稿，其中提供有關(guān) JSR 目標以及專家組計劃在其開發(fā)過程中使用的流程的信息。

修訂現(xiàn)有規(guī)范

現(xiàn)有的規(guī)格以及它們相關(guān)的 RI 和 TCK 由指定的維護負責人使用本文檔中介紹的過程進行維護。在遵守 JCP 成員關(guān)于改進的愿望的同時，維護負責人應長期承擔規(guī)范，RI 和 TCK 的所有權(quán)。因此，維護線索應是對其規(guī)格進行所有重大修訂的規(guī)范線索，但他們無權(quán)決定何時進行重大修訂。這應由 EC 響應任何 JCP 成員可以發(fā)起的 JSR 修訂版來決定。提交者應做出合理的努力來招募前專家組的成員，以加入任何此類修訂工作。

保護已安裝的基座并防止碎片

對Java編程語言、Java 空間中的Java虛擬機（JVM）、Java本機接口（JNI）模塊和包，或僅作為 Java SE 一部分交付的其他包的更改，如果跨平臺版本執(zhí)行的不一致，可能會嚴重破壞安裝基礎。為了保護已安裝的用戶群，任何此類更改都只能在 Java SE 的傘形 JSR 中接受和執(zhí)行。

為了防止出現(xiàn)碎片，新的平臺版本規(guī)范不得實質(zhì)性地復制現(xiàn)有平臺版本或概要文件。

配置文件和API規(guī)范以當前平臺版本為目標

所有新的或修訂的規(guī)范必須與目標平臺版本規(guī)范的最新版本兼容。為了實現(xiàn)此目的，所有定義新的概要文件規(guī)范或修訂現(xiàn)有概要文件規(guī)范必須參考其所基于的平臺版本規(guī)范的最新版本，或者引用正在通過活動 JSR 開發(fā)的該規(guī)范的更新版本。

平臺包含

需要 JSR 提交來說明 JSR 的 RI 和 TCK 是作為概要文件還是平臺版本的一部分，以獨立方式或兩者同時提供。關(guān)于特定 JSR 是否包含在概要文件或平臺版本中的最終決定由概要文件或平臺版本 JSR 的規(guī)范負責人和專家組做出的相關(guān) JSR 的 EC 選票確認。如果概要文件或平臺版本的規(guī)范主管拒絕了包含請求，則 JSR 必須提供獨立的 RI 和 TCK 。

在最初獨立交付后，可以將技術(shù)合并到概要文件或平臺版本中。提議成為概要文件或平臺版本的一部分并考慮停止獨立可用性的新版 API 的 JSR 必須說明進行此更改的理由，并且必須告知公眾要終止獨立 RI 的意圖，并且 TCK 提前發(fā)布了一個 JSR。

JSR 審查

當收到 JSR 時，PMO 將為其提供一個跟蹤號，創(chuàng)建其 JSR 頁面，向公眾公布擬議的 JSR，并開始進行JSR 審查。對 JSR 的評論應通過 JSR 的公眾反饋交流機制提供。意見應轉(zhuǎn)發(fā)給 EC 進行審議，并應在JSR 頁面上提供（類似意見可以合并）。

有興趣加入專家組或作為貢獻者參與的成員應通過告知規(guī)范負責人和 PMO 來表明自己的身份。我們鼓勵規(guī)范負責人在此期間積極招募小組成員和貢獻者，并用希望提供幫助的人的名字更新 JSR 頁面，因為表現(xiàn)出對 JSR 的廣泛興趣和代表性的多樣性將大大增加 EC 批準它的機會。

如果在批準 JSR 之前擔任規(guī)范負責人的成員退出了 JCP，PMO 將要求初步專家組選擇一名替代者。

許可條款的披露

規(guī)范負責人負責開發(fā)參考實現(xiàn)和技術(shù)兼容性工具包，并按照 JSPA 中的說明為其授予許可。規(guī)范負責人必須在 JSR 評審開始之前向 EC 提供建議的規(guī)范，RI 和 TCK 許可證的完整副本。PMO 將在 JSR 頁面上發(fā)布許可證。EC 委員應提供有關(guān)條款的反饋，以表明整個社區(qū)對條款的反應。如果 EC 委員認為擬議的許可條款與 JCP 內(nèi)使用的許可指導方針不兼容，則對提議的 JSR 的投票應延遲到 Oracle 法律機構(gòu)對此事發(fā)表意見之前。

JSR 批準投票和專家組的形成

在 JSR 審查之后，EC 委員應審查 JSR 和收到的任何評論，并投票決定是否應批準 JSR。

如果 JSR 批準投票失敗，PMO 應將所有 EC 評論發(fā)送給 JSR 提交者，后者可以修改 JSR 并在14天內(nèi)重新提交。如果在此期間未收到修訂的 JSR，則原始 EC 決定生效， JSR 應予關(guān)閉。如果收到修訂的 JSR，則 PMO 應將其發(fā)布到 JSR 頁面，向公眾公布修訂的 JSR，然后將其發(fā)送給所有 EC 委員以進行 JSR 復議投票。如果投票失敗，則關(guān)閉 JSR。

在獲得 JSR 批準后，PMO 指示規(guī)范負責人正式創(chuàng)建專家組，并確定將充當貢獻者的成員。PMO 將相應地更新 JSR 頁面。

迭代更新

對于迭代 JSR，規(guī)范負責人可以在最終發(fā)布更新 JSR 的意圖之前的任何時間通知 PMO。規(guī)范負責人應提供下一次迭代的開始日期，下一次迭代的時間表，下一次迭代的版本號以及專家組的建議的初始成員。將為迭代創(chuàng)建一個新的 JSR，具有相同的 JSR 詳細信息以及新的專家組成員，版本號和時間表。迭代可能會重疊；在創(chuàng)建下一個迭代之前，不需要上一個迭代達到任何特定的里程碑。除了更改計劃和版本之外，規(guī)范負責人成員還可以提名另一位 規(guī)范負責人代表。無需為第一次或以后的迭代續(xù)訂迭代的 JSR 而進行 JSR 批準投票，除非規(guī)范負責人建議 PMO 認為對 JSR 提交的更改是實質(zhì)性的。迭代 JSR 可能遵循維護階段流程。

2.發(fā)布JSR草案評審

開始制定規(guī)范和參考實現(xiàn)

專家組應在開始工作時考慮 JSR 中提出的要求、任何貢獻的文件或技術(shù)說明，在 JSR 審查期間收到的意見，以及如果是對現(xiàn)有規(guī)范的修訂，則由維護負責人維護的問題清單來開始工作?？梢詮呐c其他成員，行業(yè)團體，軟件開發(fā)人員，最終用戶和學者的討論中獲得其他意見。貢獻是根據(jù) JSPA 的條款進行的。目的是定義需求，然后編寫規(guī)范和原型參考實現(xiàn)草案，以供社區(qū)和公眾審查。

我們鼓勵 JSR 在開發(fā)過程中經(jīng)常提供規(guī)范和參考實現(xiàn)的公共草案，即使它們不完整。草案應以 PMO 批準的方式公開發(fā)布，并且在新的草案可用時，規(guī)范負責人應通知 PMO。規(guī)范負責人應提供一種機制，通過這種機制他們將草案通知公眾，公眾可以對這些早期草案提供反饋意見。

公眾評審

當規(guī)范的公眾評審草案準備就緒時，規(guī)范負責人應將草案發(fā)布，并將草案以及需要評審的任何其他文件發(fā)送給 PMO，PMO 將在網(wǎng)上發(fā)布這些文件，供公眾下載。此時，JCP 成員的社區(qū)評審同時進行。當 PMO 宣布可提供規(guī)范草案以供公眾評審和評論時，公共審查就開始了，該草案可根據(jù) PMO 的決定在評估許可下托管在另一個站點上。

規(guī)范負責人負責確保閱讀并考慮所有評論。如果這些意見導致對規(guī)范草案的修訂，并且這些修訂導致重大修改(專家組認為) ，那么規(guī)范負責人必須在投票開始前至少3天張貼更新的草案，并將更新后的草案(連同修改摘要)發(fā)送給 PMO。PMO 應在投票開始之前將新的草案和變更摘要張貼在 JCP 網(wǎng)站上，并應通知公眾新的草案可用。

公眾評審最終批準選票

除非“規(guī)范負責人”希望在“最終批準投票”之前發(fā)布另一份“公共審核”，否則“公共審核最終批準”投票將在“公共審核”結(jié)束時開始。投票結(jié)束時，PMO 應將 EC 成員提交的所有評論連同投票一起分發(fā)給專家組。

如果公共審核最終批準規(guī)范投票失敗，則專家組將有30天的時間來響應 EC 提出的問題更新草案并將修訂后的版本提交 PMO。如果在30天內(nèi)未收到修訂的草案，則 EC 原決定生效，PMO 將宣布 JSR 已關(guān)閉。如果收到修訂，PMO 應將其轉(zhuǎn)發(fā)給 EC 并啟動“公共審核最終批準規(guī)范重新審議”投票。投票結(jié)束時，PMO 應將 EC 成員提交的所有評論連同投票一起分發(fā)給專家組。如果投票失敗，則將關(guān)閉 JSR，并且解散專家組。如果 JSR 是對現(xiàn)有規(guī)范的修訂，則規(guī)范負責人應恢復當前規(guī)范的維護負責人的角色。

如果專家組認為這會有所幫助，則可以進行多次公開草案和審核。

3.JSR定案

完成規(guī)格

如果公眾審查最后批準投票(或復議投票)成功，專家組應通過完成其認為對意見作出必要修改的方式編制最終規(guī)范草案。

完成RI和TCK

規(guī)范負責人負責完成 RI 和 TCK。需要針對多個平臺的 JSR 來支持每個環(huán)境，這可能需要為每個環(huán)境提供單獨的 RI 和 TCK。如果 RI 和 TCK 發(fā)現(xiàn)規(guī)范中定義不足、不完整或模棱兩可的地方，規(guī)范負責人應與專家組合作糾正這些缺陷，然后將修訂后的規(guī)范連同變更摘要一起發(fā)送給 PMO。信息應發(fā)布在 JCP 網(wǎng)站上。專家組應繼續(xù)審議在此期間收到的任何進一步意見。

建立初級TCK申訴流程

規(guī)范負責人還負責建立一個明確定義的一級 TCK 申訴程序，以應對 TCK 中包含的測試挑戰(zhàn)。此過程必須在 TCK 文檔中描述。對初級決策不滿意的實施者應通過向 PMO 發(fā)送電子郵件，記錄他們的擔憂，向 EC 申訴。PMO 將把請求連同從管理層收到的關(guān)于初級決定理由的任何信息一起分發(fā)給 EC，并發(fā)起為期7天的申訴投票。

根據(jù)TCK上訴更新可交付成果

根據(jù)問題的性質(zhì)，一個成功的 TCK 挑戰(zhàn)將需要更新 TCK、規(guī)范和 RI 中的一個或多個。在 TCK 上訴投票成功結(jié)束后的30天內(nèi)，維護負責人必須在必要時更新這些可交付成果，并在將規(guī)范(如果更改了)和更新后的 RI 或 TCK 的 URL 在 JCP 網(wǎng)站上發(fā)布時向 PMO 報告這些更改。

最終版本

當專家組確信 TCK 提供了足夠的測試覆蓋范圍，RI 正確地執(zhí)行了規(guī)范，RI 通過了 TCK，規(guī)范負責人應將規(guī)范的最終草案連同關(guān)于 EC 委員如何獲得 RI 和 TCK 進行評估的說明一起發(fā)送給 PMO。PMO 應向 EC 分發(fā)材料，并公布最終版本。EC 的任何意見應由 PMO 送交專家組。

為了協(xié)助 PMO 跟蹤“活躍 JSR ”的數(shù)量，在提交最終材料時，規(guī)格負責人應通知 PMO，是否期望通過維護版本或新的后續(xù) JSR 進一步開發(fā) JSR。作為最終版本的一部分提交的 TCK 必須滿足以下要求：

• 包括關(guān)于 TCK 的配置和執(zhí)行的文件、使用 TCK 所需的任何其他信息(例如所提供的任何工具的文件)、第一級 TCK 上訴程序的定義和說明，以及除了通過 TCK 測試之外必須滿足的兼容性要求

• 兼容性要求至少必須指定所有兼容的實現(xiàn)

• 完全實施規(guī)范，包括所有必需的接口和功能，以及不得修改、子集、超集或以其他方式擴展許可方名稱空間，或在許可方名稱空間中包含任何模塊、公共或受保護包、類、 Java 接口、字段或方法，但實現(xiàn)的規(guī)范或規(guī)范所要求/授權(quán)的除外。

• 除非規(guī)范或 TCK 明確允許例外，否則必須滿足這些要求。

• 附有測試工具，腳本或其他方式，以自動化測試執(zhí)行和結(jié)果記錄。

• 包括一個 TCK 覆蓋范圍文檔，該文檔將幫助 EC 委員評估 TCK 的質(zhì)量。該文檔應包括對 TCK 中包含的文檔的概述，對用于驗證 TCK 質(zhì)量的方法的描述，用于衡量規(guī)范的 TCK 測試覆蓋率的標準，所達到的測試覆蓋率編號以及充分性的依據(jù) TCK 質(zhì)量及其測試范圍。

• 提供100％簽名測試覆蓋率。這些測試必須確保完全實現(xiàn)了規(guī)范要求的所有 API 簽名，并且僅將規(guī)范要求的 API 簽名包括在 JSR 的命名空間中。

• TCK 許可條款必須允許實施者自由和公開地與所有有關(guān)方面討論測試過程和詳細的 TCK 測試結(jié)果。

EC 成員可以在7天內(nèi)提出異議。異議必須僅限于認為公開審查和最終審查之間的具體變化太大而不能被視為更正或澄清的聲稱。PMO 將評估異議要求，如果得到證實，規(guī)格負責人將有30天的時間響應 EC 的要求修改規(guī)范，RI 和 TCK，并將修改后的材料重新提交給 PMO。

如果在30天內(nèi)未收到任何回復，則 EC 原決定生效，PMO 將關(guān)閉 JSR，專家組將解散。如果 JSR 是對現(xiàn)有規(guī)范的修訂，則規(guī)范負責人應恢復當前規(guī)范的維護負責人的角色。

如果收到答復，則 PMO 應將其分發(fā)給所有 EC 委員以進行最終批準復議投票。投票結(jié)束時，EC 委員提交的所有投票意見應由 PMO 分發(fā)給專家組。如果復議投票失敗，JSR 將被關(guān)閉，專家組將解散。如果 JSR 是對現(xiàn)有規(guī)范的修訂，則規(guī)范負責人將恢復當前規(guī)范的維護負責人的角色。

在收到最終發(fā)布材料的14天內(nèi)，PMO 應在 JCP 網(wǎng)站上發(fā)布規(guī)范和有關(guān)如何獲取 RI 和 TCK 的信息的鏈接，并應向成員和公眾宣布這些材料的可用性。已發(fā)布的 TCK 信息必須包括任何利害關(guān)系方免費獲得 TCK 文檔副本的方法。最終版本發(fā)布后，專家組將完成其工作。規(guī)范負責人通常將成為維護負責人，并可以請專家組成員和其他人員擔任該角色。

維護負責人必須確保到 RI 和 TCK 的鏈接仍然有效。如果鏈接不起作用，則維護負責人將在 PMO 通知后的30天內(nèi)進行更正。如果問題未得到糾正，PMO 將啟動 JSR 撤回投票（如果尚未完成維護發(fā)布）或維護發(fā)布撤回投票（如果已進行維護發(fā)布），以確定是否應判定維護負責人已放棄 JSR。如果投票通過，則 JSR 本身或相關(guān)的維護版本將被標記為已撤回。

6.主流 OpenJDK builds

Build	LTS	寬松式許可證	經(jīng)過 TCK 測試	未修改上游的構(gòu)建	提供商業(yè)支持
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規(guī)范要求（JSR）的特定是否符合要求。 它是 Java Community Process中批準的 JSR 所需的三部分內(nèi)容之一。用于檢查是否兼容標準 Java SE。

OpenJDK Community 領(lǐng)導的 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）產(chǎn)出的 OpenJDK 是 Java SE 的官方參考實現(xiàn)，只產(chǎn)生 OpenJDK 源碼，并不提供可以直接使用的二進制文件格式?，F(xiàn)在能直接使用的二進制文件格式的 JDK 都是被編譯之后的程序。

自 Java SE 7開始往后的版本，所有的 JDK 都源自于 Open JDK(OpenJDK 與 其他 JDK 的關(guān)系就和 Linux 與它的眾多發(fā)行版是一樣一樣的)。所以嚴格意義上來說 Oracle JDK 也是 Open JDK 的一個發(fā)行版而已。

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

AdoptOpenJDK

截止2021年5月8日，AdoptOpenJDK 官網(wǎng)的聲明：

ojdkbuild

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

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

根據(jù) OpenJDK 的 Gaining Access to the JCK 的描述：

Java 兼容性工具包（又稱 JCK 或 TCK for Java SE）免費提供給計劃基于從 OpenJDK 派生的代碼部署兼容 Java 實現(xiàn)的開發(fā)人員，或者正在參與 OpenJDK 研究、錯誤修復、代碼增強和/或到其他硬件/軟件體系結(jié)構(gòu)的端口的開發(fā)人員。

OpenJDK Community 會給簽署了 TCK 許可協(xié)議（OCTLA）的廠商或組織提供 JCK。

要想知道一個提供商的 Open JDK build 是否通過 TCK 測試，除了看提供商自己的官方聲明之外，還可以查看 OpenJDK Community 提供的 OCTLA 協(xié)議簽署者列表是否有該提供商。

理論上通過了 TCK 測試的 JDK 在 Java SE 標準規(guī)范功能上是互相兼容的，為什么是 Java SE 標準規(guī)范功能才互相兼容呢？

因為有的機構(gòu)在實現(xiàn) Java SE 標準規(guī)范功能后，會在 JDK 中加入一些自己的特色功能，但是這個特色功能可能并不是每個 JDK 都有，所以如果在編程序時使用了某家 JDK 的特色功能，換個別家的 JDK 可能就會出現(xiàn)各種未知問題(個人猜測，也可能是根本跑不起來)。

其實通過了 TCK 測試的 JDK 之間互換 ，在程序只用 Java SE 的規(guī)范功能的情況下也可能存在一些小 BUG，不過確實會比沒有通過 TCK 測試的要好上不少(這也沒辦法，正常編程有時候刪個注釋就無法運行，也沒人能解釋這種玄學問題)。

總結(jié)

其實博主也挺討厭這種一大篇理論性描述的文章，但是如果不把大致基本概念和各處的重要細節(jié)給描述清楚，在寫結(jié)論和個人猜想的時候就又會有引出一些不必要的爭吵，這些不必要的爭吵又大多是因為對基本概念和各處的重要細節(jié)了解的不對等引起的。也是挺無奈的...

能看到此處的各位都是絕對的勇士，至少在沒有緊急且重大的問題的時候，博主是看不下去這種長度的文章的，再次獻上最高敬意，閑話就不說了，下面開始總結(jié)。

自 Java SE 7開始往后的版本，所有的 JDK 都源自于 Open JDK(OpenJDK 與 其他 JDK 的關(guān)系就和 Linux 與它的眾多發(fā)行版是一樣一樣的)。

OpenJDK Community 領(lǐng)導的 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）產(chǎn)出的 OpenJDK 是 Java SE 的官方參考實現(xiàn)，只產(chǎn)生 OpenJDK 源碼，并不提供可以直接使用的二進制文件格式?，F(xiàn)在能直接使用的二進制文件格式的 JDK 都是被編譯之后的程序。OpenJDK 官網(wǎng)指向的可下載二進制文件的地址，實際是 Oracle’s OpenJDK builds 下載的地址。沒錯，這也是被 Oracle 編譯后的版本。

OpenJDK 是由 OpenJDK Community 、Oracle、IBM 領(lǐng)導，連同 Alibaba，Amazon，Ampere，Azul，BellSoft，Canonical，F(xiàn)ujitsu，Google，Huawei，Intel，Java Community，JetBrains，London Java Community，Microsoft，Red Hat，SAP，SouJava，SUSE，Tencent，Twitter ，VMWare 等第三方共同開發(fā)、維護的 Java SE 開源參考實現(xiàn)。

OpenJDK 具體版本的開發(fā)標準是 Java Community Process（JCP，Java 社區(qū)進程） 發(fā)布的  Java Specification Requests（JSR，Java規(guī)范請求）。

作為 OpenJDK Project（Java SE 7 - Java SE 9）/ JDK Project（Java SE 10及其以后）開發(fā)標準的 JSR 是眾多由 JCP 成員發(fā)起的 JSR 草案在經(jīng)過：JSR 草案發(fā)起、JCP 公眾評審、JSR最終定案、 JCP 的 EC 評審等步驟后，成功誕生的 JSR 聚合而成的。

下面用一張圖簡單概括本篇文章的要點：

由于本篇文章內(nèi)容太長，OpenJDK builds 與 OracleJDK 的選擇問題就留到下一章單獨開一篇專門來寫（不過我想認真看完這一章的朋友，應該已經(jīng)清楚知道了他們的區(qū)別以及什么情況下應選擇哪個版本了吧）。

到此，關(guān)于“java中的OpenJDK是什么”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

本文名稱：java中的OpenJDK是什么
標題URL：http://www.muchs.cn/article14/jiohde.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App設計、App開發(fā)、企業(yè)建站、用戶體驗、響應式網(wǎng)站、網(wǎng)頁設計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)