碼農飛升記-04-OracleJDK 與 OpenJDK 的區別和聯繫以及 OracleJDK builds 與其他 OpenJDK builds 的選擇問題

在前兩篇 OracleJDK是什麼?OracleJDK的版本怎麼選擇? 和 OpenJDK是什麼? 中分別介紹了 OracleJDK 和 OpenJDK 的來歷以及概念，那可能就有小夥伴要問了：那我到底該選擇使用什麼 JDK 呢？

要想知道 OracleJDK 與 OpenJDK 的區別和聯繫以及 OracleJDK builds 與其他 OpenJDK builds 的選擇問題，沒有看過前文的朋友，強烈建議先理清楚 OracleJDK 和 OpenJDK 的基本概念，具體情況可以前往 OracleJDK是什麼?OracleJDK的版本怎麼選擇? 和 OpenJDK是什麼? 詳細了解。

1.OracleJDK 與 OpenJDK 的區別和聯繫

在正式講解 OracleJDK 與 OpenJDK 的區別和聯繫之前，必須先了解 OracleJDK 與 OpenJDK 到底指的是什麼？或者說是它們有什麼含義。

1.”OracleJDK” 這個單詞的幾種含義

根據 Java Platform Group 產品管理高級總監 Donald Smith 在” Oracle JDK Releases for Java 11 and Later “中的描述：

What should we call them?

Ideally, we would simply refer to all Oracle JDK builds as the 「Oracle JDK,」 either under the GPL or the commercial license depending on your situation. However, for historical reasons while the small remaining differences exist, we will refer to them separately as Oracle』s OpenJDK builds, and the Oracle JDK.

OracleJDK builds 實際上包括了一個開源版本的 Oracle’s OpenJDK builds(基於 GPL 開源)和商業版本的 Oracle JDK builds。

目前 “OracleJDK” 這個單詞常見的幾種含義（視情況可能存在更多含義）：

  1. 由 Oracle 公司推出的商業 JDK (最常用)
  2. 由 Oracle 公司推出的 JDK (Oracle JDK builds下所有的 JDK)
  3. OracleJDK builds

在大部分情況下的 OracleJDK 指的是 Oracle 公司推出的商業版 JDK。

2.”OpenJDK” 這個單詞的幾種含義

目前 “OpenJDK” 這個單詞常見的幾種含義（視情況可能存在更多含義）：

  1. OpenJDK Community（ OpenJDK 社區）
  2. OpenJDK Project / JDK Project（JDK 項目，產出的 OpenJDK 是 Java SE 的官方參考實現，只產生 OpenJDK 源碼）
  3. OpenJDK（只有源碼）
  4. 沒有經過廠商修改，直接由 OpenJDK Project / JDK Project 產出的 OpenJDK 編譯出來的 OpenJDK builds
  5. OpenJDK builds（各廠商根據 OpenJDK Project / JDK Project 產出的 OpenJDK 構建的發行版）
  6. 除 OracleJDK 之外的 OpenJDK builds
  7. Oracle』s OpenJDK builds（ Oracle 的 OpenJDK 構建（非商業））

3.隨意簡寫要人命系列！！！

為什麼會說隨意簡寫要人命呢？

目前大部分關於 OracleJDK 和 OpenJDK 的文章都在說「 OracleJDK 和 OpenJDK 該怎麼選」。但是部落客想說的是「 OracleJDK 與 OpenJDK 真的有那麼難選擇么？」

部落客個人認為：難點並不在怎麼選擇，而在於不了解 OpenJDK 的概念，以及沒有發現很多文章（截止2021年6月6日）使用 “OpenJDK” 的時候其實都有意無意的進行了簡寫。

其實一般情況下正常的簡寫縮寫都不要緊，但是本來意義就比較多的 OpenJDK，被他們這一簡寫，就容易讓不了解它的人張冠李戴。

舉個例子：

例1：OracleJDK 與 OpenJDK 怎麼選擇?

這裡的 OpenJDK 的含義：

  • 在有的文章里，指的是：上面的 OpenJDK 的第 6 種含義——–除 OracleJDK 之外的 OpenJDK builds
  • 在有的文章里，指的是：上面的 OpenJDK 的第 7 種含義——–Oracle』s OpenJDK builds（ Oracle 的 OpenJDK 構建（非商業））

例2：OracleJDK 與 OpenJDK 的區別

這裡的 OpenJDK 的含義：

  • 在有的文章里，指的是：上面的 OpenJDK 的第 2 種含義——–OpenJDK Project / JDK Project（JDK 項目，產出的 OpenJDK 是 Java SE 的官方參考實現，只產生 OpenJDK 源碼）
  • 在有的文章里，指的是：上面的 OpenJDK 的第 3 種含義——–OpenJDK（只有源碼）
  • 在有的文章里，指的是：上面的 OpenJDK 的第 4 種含義——–沒有經過廠商修改，直接由 OpenJDK Project / JDK Project 產出的 OpenJDK 編譯出來的 OpenJDK builds
  • 在有的文章里，指的是：上面的 OpenJDK 的第 5 種含義——–OpenJDK builds（各廠商根據 OpenJDK Project / JDK Project 產出的 OpenJDK 構建的發行版）
  • 在有的文章里，指的是：上面的 OpenJDK 的第 6 種含義——–除 OracleJDK 之外的 OpenJDK builds
  • 在有的文章里，指的是：上面的 OpenJDK 的第 7 種含義——–Oracle』s OpenJDK builds（ Oracle 的 OpenJDK 構建（非商業））

例3：Microsoft 加入 OpenJDK

這是一個新聞標題，這裡的 OpenJDK 有可能指的是：

  • 上面 OpenJDK 的第 1 種含義——–OpenJDK Community（ OpenJDK 社區）
  • 上面 OpenJDK 的第 2 種含義——–OpenJDK Project / JDK Project（JDK 項目，產出的 OpenJDK 是 Java SE 的官方參考實現，只產生 OpenJDK 源碼）

PS：

  • 有的新聞標題加上了 ” 項目 / Project “，使人一目了然知道他講的是什麼事。有的新聞全程沒有加 ” 項目 / Project “，導致 Microsoft 加入的 OpenJDK 到底是什麼，得像上面兩個例子一樣—靠猜。

4.懇請各位今後不要隨意簡寫 “OpenJDK”，請務必把 “OpenJDK XXX” 描述完整

看到這裡，各位請試想一下，把自己想像成還不了解 OpenJDK 的完整概念以及 “OpenJDK” 這個單詞蘊含的眾多意義的時候：

在這個時候你去搜索與 “OpenJDK” 相關的文章來看，結果剛看了這個文章說的 “OpenJDK” 是這個意思，然後又看了另外一個文章，裡面的 “OpenJDK” 又是另外一個意思，運氣比較差的再搜一篇文章來看，結果三篇文章說的都不是一個含義的 OpenJDK，這就讓人很崩潰（其實就是因為沒有把 “OpenJDK XXX” 描述完整，直接用 “OpenJDK” 代指了這個含義，所引發的歧義）。

而且更要命的是很多文章也沒有把完整的 OpenJDK 到底是什麼給說清楚，就只說了他文章所指那個意思的相關內容。

這會直接導致不了解 OpenJDK 的人陷入迷茫，本來抱著求知的態度來的，結果越看越懵。

死磕到底且知道怎麼扒官方文件來看的人，或許能靠自己的死磕精神把這些東西給弄清楚，那些不知道該怎麼找官方資料的小白怎麼辦？那要是有人認為自己認知的 OpenJDK （”OpenJDK” 的其中幾個含義）就是整個 OpenJDK 的含義，然後寫了篇文章出來，然後被不知情的人當成科普或者參考資料看了，這不就誤人子弟了么。

“OpenJDK” 之所以會存在那麼多含義，多到讓不了解的人暈頭轉向，問題的根源大多在於隨意簡寫。因為圖方便簡寫、因為別人都這麼寫才簡寫、因為自己都不太清楚具體含義才簡寫。無論是因為什麼，這都會加大新人理解這個概念的難度，也會增加已經理解了概念的人之間的溝通難度，尤其是大多數人都在這麼做的時候。

舉個例子：

  1. OracleJDK 和 OpenJDK 的關係
  2. OracleJDK 和 OpenJDK builds 的關係
  3. OracleJDK 和 OpenJDK Project 的關係
  4. OracleJDK 和 OpenJDK Community 的關係
  5. OracleJDK 和 Oracle』s OpenJDK builds 的關係
  6. OracleJDK 和除 OracleJDK 之外的 OpenJDK builds 的關係

了解 OracleJDK 與 OpenJDK 概念各位自然知道，這六個標題可以寫出至少五篇關注的主體不同的文章，然而這些主體不同的文章，目前大部分藏身於一個叫：OracleJDK 和 OpenJDK 的關係 的標題中，甚至有些文章並不只是標題進行了簡寫，連文章內容裡面都直接用 “OpenJDK” 代指各種意義。

那在這種情況下，作為初學者的人該怎麼理解這個概念呢?

可想而知，一個 “OpenJDK” 的簡寫對新手的即可造成毀滅性打擊，能從中走出來的人，要麼花費了大量的時間查找相關資料，要麼在大量查找相關文章時幸運找到一個介紹 OpenJDK 比較完整的文章，要麼在使用 OpenJDK builds 很多年後突然靈光一閃。想通了這個問題。但是沒走出來的人，可能就一直混沌下去了。

這樣真的好嗎？寫文章不就是在儲存自己了解的知識（以防自己忘記）的同時，方便他人查閱，指導他人學習的嗎？

如果反而把他人弄得迷迷糊糊，甚至多年以後自己忘了相關知識，來看自己以前寫的東西，結果把自己也繞進去了，這不是有背最初寫下這個文章的意願嗎？

想要解決這個問題也很簡單，那就是把 “OpenJDK XXX” 描述完整，不要隨意簡寫，不要吝嗇自己的那幾個用於描述的語句。有時候正常說話都還會存在歧義，就更別提 “OpenJDK” 這個簡寫就歧義滿天飛的單詞了。

所以再度懇請各位，今後不要隨意簡寫 “OpenJDK”，請務必把 “OpenJDK XXX” 描述完整，無論是使用中文還是英文，都請把 “OpenJDK XXX” 描述完整。

5.OracleJDK 與 OpenJDK 的區別和聯繫

其實看到這裡，我相信不用我說，大家對他們的區別和聯繫都已經心知肚明了。那各位不要嫌我煩，我再為大家梳理一下。

Java 原名 Oak 是 Sun Microsystems 公司的 James Gosling 及其團隊於 1995 年 5 月推出的 Java 程式設計語言 和 Java 平台 的總稱。

Java 是一種廣泛使用的電腦程式語言，擁有跨平台、面向對象、泛型編程的特性，廣泛應用於企業級Web應用開發和移動應用開發。

Java 平台 由 Java 虛擬機（Java Virtual Machine，JVM） 和 Java 應用編程介面（Application Programming Interface，API） 構成。

1995年5月23日，Sun 公司在 Sun world 會議上正式發布 Java 和 HotJava 瀏覽器。

1996年1月23日，Sun 公司發布了 Java 的第一個開發工具包（JDK 1.0），這是 Java 發展歷程中的重要里程碑，標誌著 Java 成為一種獨立的開發工具。

JDK 是 Java Development Kit 的縮寫，翻譯過來就是 Java 開發工具包。

Sun 在 JavaOne 2006 中宣布 Java 將成為開源軟體並建立了 Open 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 中刪除。

Oracle JDK 源自 Sun JDK（2009年 Oracle 收購 Sun），Oracle JDK 自然就是 Oracle 公司出品的 JDK。所以 Oracle JDK 就是 Oracle 公司開發維護的 Java 開發工具包。

自 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 聚合而成的。

所以 OracleJDK 與 OpenJDK 的區別和聯繫可以用一張圖解釋：

02-OracleJDK和OpenJDK的關係.png (1161×841) (gitee.com)

由上圖可知，OracleJDK 是 Oracle 基於 OpenJDK Project（Java SE 7 – Java SE 9）/ JDK Project（Java SE 10及其以後）在 OpenJDK Community （OpenJDK 社區）的領導下，以 Java Community Process（Java 社區進程）製作的 Java Specification Request（Java 規範請求）為標準，製作出的 OpenJDK 所製作的商業版構建。本質上來說，OracleJDK 也是 OpenJDK 的發行版之一。

2.主流 OpenJDK builds

Build LTS 寬鬆式許可證 經過 TCK 測試 未修改上游的構建 提供商業支援
AdoptOpenJDK/Adoptium 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 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 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，自行添加了 Huawei bisheng JDK 和 Tencent Kona。在粗略驗證數據準確性(例如: 查看對應 JDK 的官網描述，對描述不詳細的向官方人員求證)後整理成此列表(經過驗證，維基百科少部分 JDK 的數據未及時更新，所以可能會和此列表有些許出入)。
  • 關於 Tencent Kona 是否通過 JCK/TCK 的問題，由於騰訊官方沒有在其官網明確說明，部落客就這個問題諮詢了騰訊雲客服 與騰訊雲客服的聊天記錄 得到的回答是通過了測試(不過部落客個人認為，該客服人員的回答僅供參考)。

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

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

AdoptOpenJDK

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

Java Compatibility Kit (JCK) / TCK Compliance

At 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.

Alibaba Dragonwell

截止2021年6月6日，Alibaba Dragonwell 官網的聲明：

OPENJDK DOWNSTREAM

Alibaba Dragonwell is a downstream version of OpenJDK and is a reliable alternative to OpenJDK in the production environment.

* Alibaba Dragonwell is not TCK tested.

Huawei Bisheng JDK

截止2021年6月6日，畢昇JDK 11 的 Gitee 開源程式碼倉庫中 issue 的回答：

05-BiShengJDK_issue.png (922×1083) (gitee.com)

ojdkbuild

截止2021年6月6日，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.

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

根據 OpenJDK 的 Gaining Access to the JCK 的描述：

Gaining Access to the JCK

The 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.

Process

To 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.

Support

Support 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 測試的要好上不少(這也沒辦法，正常編程有時候刪個注釋就無法運行，也沒人能解釋這種玄學問題)。

3.OpenJDK builds 的選擇

OpenJDK builds 具體的選擇標準，這裡也不敢隨便講，畢竟每個人的需求、應用的環境、開發規模都不同。

所以這裡先看一下各方大佬的選擇結果，他們來自世界各地，是獨立或隸屬各種不同規模的公司的開發人員、團隊領導、項目經理、架構師、技術顧問、首席高層。

他們的選擇在一定程度上具有參考價值，下面就來就看看他們的選擇吧。

《JVM Ecosystem Report 2020》(2020年JVM生態系統報告)截選

根據 SNYK 發布的 《JVM Ecosystem Report 2020》(2020年JVM生態系統報告)：

您在生產環境中為主要應用程式使用哪個Java供應商的JDK?

08-0007.jpg (3508×2481) (gitee.com)

根據上圖，我們可以知道2020年的 JDK 佔有率排名是：

  1. OracleJDK—34%
  2. AdoptOpenJDK 搭載 OpenJDK HotSpot VM—24%
  3. Oracle’s OpenJDK—15%
  4. 其他 OpenJDK builds 的總和 —14%
  5. Amazon Corretto—4%
  6. Azul Zulu—4%
  7. AdoptOpenJDK 搭載 Eclipse OpenJ9 VM—3%

你付錢給誰

09-0009.jpg (3508×2481) (gitee.com)

當選擇付費時,人們更傾向於選擇的JDK排行是：

  1. OracleJDK—55%
  2. Red Hat build of OpenJDK—17%
  3. AdoptOpenJDK/Adoptium & IBM Java SDK—16%（ AdoptOpenJDK/Adoptium 的商業支援是 IBM 提供的）
  4. Azul Zulu—12%

您在生產環境中為主應用程式使用哪個 Java SE 版本?

10-0012.jpg (3508×2481) (gitee.com)

生產環境中最常使用的 Java SE 版本排行是：

  1. Java SE 8—64%
  2. Java SE 11—25%
  3. Java SE 12—4%
  4. Java SE 7 及其以前版本—3%
  5. Java SE 9—2% / Java SE 10—2%

在生產環境中採用新的JDK版本的方法是什麼?

11-0014.jpg (3508×2481) (gitee.com)

生產環境中決定 JDK 版本的依據排行是：

  1. 使用長期支援（LTS）版本—55%
  2. 根據每個版本的特性來決定—22%
  3. 還不知道怎麼選擇—12%
  4. 始終保持 Java 最新版本—11%

對《JVM Ecosystem Report 2020》(2020年JVM生態系統報告) 感興趣的朋友,可以通過這裡查看完整版: 《JVM Ecosystem Report 2020》(2020年JVM生態系統報告)

總結

這裡簡單概括一下各方大佬的的選擇標準：

個人推薦的選擇JDK的標準

首先還要強調的一點就是，從 Java SE 7 開始 OpenJDK 成為了 Java SE 的官方參考實現，而 OpenJDK 6 實際上是在 OpenJDK 7的基礎上去掉 Java SE 7 的特性得到的。

要選擇適合自己的 JDK，分成兩步：

  1. 明確用途（以確定具體的 Java SE 版本的選擇）
  2. 在明確 Java SE 版本的情況下，根據自己的條件和產品需要的特性選擇適合的 JDK builds

1.明確用途

首先要明確用途，以確定具體的 Java SE 版本。

學習/個人使用

如果是用於學習/個人使用，那理論上Java 8及其之後的所有版本都可以。
不過個人推薦 Java SE 8 （目前生產環境使用的最多）和當前最新的 LTS 版本（可以學習已經穩定的最新技術）。

嘗鮮

如果是想了解最前沿的 Java 的新特性、新技術，那就直接上最新 Java SE 版本吧，只有它能滿足你的需求。

生產

如果是需要用於生產環境，最好是求穩，所以長期支援（LTS）版本優先。
目前的長期支援（LTS）版本有：Java SE 8（特殊的 LTS 版本）、Java SE 11以及預計在今年9月份發布的 Java SE 17。

維護老項目

在維護老項目方面，最好不要更改原本使用的 JDK （老項目更改 JDK 極其容易一改一堆坑，掉入萬丈深淵），風險極高。常言道：能跑的程式碼最好就不要動它，更何況是直接更改運行環境呢？。

如果實在要改的情況下：

Java SE 8 以前的版本，推薦修改到 Java SE 8（相比 Java SE 11，Java SE 8的改動更小，改動之後的坑更少）。
Java SE 8 及其以後的版本，推薦修改到 Java SE 11。

不怕麻煩，不怕被炒，也可以頂著可能要把整個項目重寫一遍的風險，不管原本運行的什麼版本直接無腦改用最新的LTS版本。

創建新項目

除需要特殊功能的情況下，盡量都選擇當前最新的 LTS 版本。

2.挑選 JDK builds

在明確了需要的 Java SE 版本之後，根據自己的條件和產品需要的特性選擇適合的 JDK builds。

Java SE 6以前(不包括 Java SE 6)的版本

如果你根據自己的條件和產品需要的特性，最終選擇了Java SE 6以前的版本，那你的選擇就只有 OracleJDK。因為 Sun JDK 6發布之後才建立的 OpenJDK Community，大多數廠商的 OpenJDK 是從 Java SE 8開始構建的。
所幸的是在2019年4月16日以前發布的 OracleJDK 採用 Binary Code License 可以免費商用，所以不用擔心付費問題（不使用商業功能和嵌入式設備的情況下）。

Java SE 8以前(不包括 Java SE 8)的版本

如果你根據自己的條件和產品需要的特性，最終選擇了Java SE 8以前的版本，那你的選擇面會稍微廣一點包含：OracleJDK、Oracle’s OpenJDK、Azul Zulu、IBM Java SDK 。

他們都是免費商用，提供可選的付費商業支援。個人推薦 OracleJDK ，在 Java SE 8以前的版本中比較主流，有了 Bug 更容易找到解決辦法。

Java SE 8及其以後的版本

如果你根據自己的條件和產品需要的特性，最終選擇了Java SE 8及其以後的版本，那你的選擇面就廣了。上面提到的 主流 OpenJDK builds 都可以選擇。

如果選用 OracleJDK，最主要的就是付費問題：

  • 在2019年4月16日以前發布的版本採用 Binary Code License 可以免費商用（不使用商業功能和嵌入式設備的情況下）—Java SE 8u201(CPU)/8u202(PSU)及其以前版本。
  • 在2019年4月16日以後發布的版本採用 Java SE OTN License 商用收費—Java SE 8u211(CPU)/8u212(PSU)及其以後版本。

除 OracleJDK 以外的 OpenJDK builds 絕大多數可以免費商用，個別 OpenJDK build 還提供可選的付費商業支援。

根據上文的《JVM Ecosystem Report 2020》(2020年JVM生態系統報告)，個人推薦這三個 OpenJDK builds：AdoptOpenJDK 、Amazon Corretto、Azul Zulu。

當然也可以嘗試中國廠商的 OpenJDK builds ：Alibaba Dragonwell、Huawei bisheng JDK、Tencent Kona。

參考資料(排名不分先後)

Java發展歷程
Donald Smith-Oracle JDK Releases for Java 11 and Later
Oracle Blogs-Donald Smith
維基百科-GPL
MBA智庫.百科-GPL
百度百科-GPL
Oracle JDK 主頁
維基百科-Java
維基百科-Java版本歷史
Java CPU and PSU Releases Explained
CPU, PSU, SPU – Oracle Critical Patch Update Terminology Update
JDK Release Notes
Change to Java SE 7 and Java SE 6 Update Release Numbers
QCon 2012-Java won’t curl up and die like Cobol, insists Oracle
Java 8 release delayed until next year
Oracle’s Mark Reinhold-Java 8: Secure the train
Oracle Java SE Support Roadmap
Donald Smith-Update and FAQ on the Java SE Release Cadence
Oracle-Oracle Java SE Support Roadmap
Oracle-Binary Code License (Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX)
Oracle-Java SE OTN License (Oracle Technology Network License Agreement for Oracle Java SE)
Oracle-Oracle Java SE Licensing FAQ
RednaxelaFX-Oracle 終於要向 Java 的非付費用戶開槍了-怎麼看？
RednaxelaFX-採用java開發商業軟體需要給Oracle付錢嗎？
Oracle-Oracle Java SE and Oracle Java Embedded Products
維基百科-OpenJDK
維基百科-Java Platform, Standard Edition
百度百科-Java SE
Sun Microsystems
維基百科-JavaOne
百度百科-JavaOne
OpenJDK Community
OpenJDK Community 章程
OpenJDK Mercurial Repositories
維基百科-Java Community Process
Java Community Process
Java Community Process-JCP 2.11: Process Document
維基百科-JCP Executive Committee
Oracle’s OpenJDK
CDSN-Hern（宋兆恆）-軟體版本含義
AdoptOpenJDK-Quality
ojdkbuild-FAQ
維基百科-TCK
OpenJDK-Gaining Access to the JCK
OpenJDK-OCTLA
OpenJDK-OCTLA Signatories List
OpenJDK-Please register to get OpenJDK access to the JCK
OpenJDK-Oracle Contributor Agreement
W3Cschool-UML
CSDN-挨踢大俠-UML類圖幾種關係的總結
CSDN-郭二關-UML與Java– UML類圖於Java的基本實現
SNYK
SNYK Blog-JVM Ecosystem Report 2020
《JVM Ecosystem Report 2020》

Tags:

VirMach 便宜 VPS

QNews

QNews