本文链接：https://blog.csdn.net/Heaven__Zhi/article/details/110840861

在前两篇 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” 这个单词常见的几种含义（视情况可能存在更多含义）：

由 Oracle 公司推出的商业 JDK (最常用)
由 Oracle 公司推出的 JDK (Oracle JDK builds下所有的 JDK)
OracleJDK builds

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

2.“OpenJDK” 这个单词的几种含义

目前 “OpenJDK” 这个单词常见的几种含义（视情况可能存在更多含义）：

OpenJDK Community（ OpenJDK 社区）
OpenJDK Project / JDK Project（JDK 项目，产出的 OpenJDK 是 Java SE 的官方参考实现，只产生 OpenJDK 源码）
OpenJDK（只有源码）
没有经过厂商修改，直接由 OpenJDK Project / JDK Project 产出的 OpenJDK 编译出来的 OpenJDK builds
OpenJDK builds（各厂商根据 OpenJDK Project / JDK Project 产出的 OpenJDK 构建的发行版）
除 OracleJDK 之外的 OpenJDK builds
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" 之所以会存在那么多含义，多到让不了解的人晕头转向，问题的根源大多在于随意简写。因为图方便简写、因为别人都这么写才简写、因为自己都不太清楚具体含义才简写。无论是因为什么，这都会加大新人理解这个概念的难度，也会增加已经理解了概念的人之间的沟通难度，尤其是大多数人都在这么做的时候。

举个例子：

OracleJDK 和 OpenJDK 的关系
OracleJDK 和 OpenJDK builds 的关系
OracleJDK 和 OpenJDK Project 的关系
OracleJDK 和 OpenJDK Community 的关系
OracleJDK 和 Oracle’s OpenJDK builds 的关系
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 的问题，由于腾讯官方没有在其官网明确说明，博主就这个问题咨询了腾讯云客服与腾讯云客服的聊天记录得到的回答是通过了测试(不过博主个人认为，该客服人员的回答仅供参考)。

自 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 占有率排名是：

OracleJDK—34%
AdoptOpenJDK 搭载 OpenJDK HotSpot VM—24%
Oracle’s OpenJDK—15%
其他 OpenJDK builds 的总和 —14%
Amazon Corretto—4%
Azul Zulu—4%
AdoptOpenJDK 搭载 Eclipse OpenJ9 VM—3%

你付钱给谁

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

当选择付费时,人们更倾向于选择的JDK排行是：

OracleJDK—55%
Red Hat build of OpenJDK—17%
AdoptOpenJDK/Adoptium & IBM Java SDK—16%（ AdoptOpenJDK/Adoptium 的商业支持是 IBM 提供的）
Azul Zulu—12%

您在生产环境中为主应用程序使用哪个 Java SE 版本?

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

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

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

在生产环境中采用新的JDK版本的方法是什么?

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

生产环境中决定 JDK 版本的依据排行是：

使用长期支持（LTS）版本—55%
根据每个版本的特性来决定—22%
还不知道怎么选择—12%
始终保持 Java 最新版本—11%

对《JVM Ecosystem Report 2020》(2020年JVM生态系统报告) 感兴趣的朋友,可以通过这里查看完整版: 《JVM Ecosystem Report 2020》(2020年JVM生态系统报告)

总结

这里简单概括一下各方大佬的的选择标准：

生产环境大多以长期支持（LTS）版本为主
目前使用最多的 Java 版本是 Java SE 8，其次是 Java SE 11
使用最多的 Java builds 仍就是 OracleJDK，其后分别依次是 AdoptOpenJDK、Oracle’s OpenJDK、Amazon Corretto、Azul Zulu。

个人推荐的选择JDK的标准

首先还要强调的一点就是，从 Java SE 7 开始 OpenJDK 成为了 Java SE 的官方参考实现，而 OpenJDK 6 实际上是在 OpenJDK 7的基础上去掉 Java SE 7 的特性得到的。

要选择适合自己的 JDK，分成两步：

明确用途（以确定具体的 Java SE 版本的选择）
在明确 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。