JDK14是运行JAVA程序不可或缺的环境安装包，功能强大的Java SE开发工具包。用于使用Java编程语言构建应用程序和组件。JDK包括用于开发和测试用Java编程语言编写并在Java平台上运行的程序的工具。安装它可以运行java程序。它包括Java SE 平台的完整实现和其他Java API，以支持Java应用程序的开发，调试和监视。Java SE使您可以在台式机和服务器上开发和部署Java应用程序。Java提供了当今应用程序所需的丰富的用户界面，性能，多功能性，可移植性和安全性。Java是世界上与其他编程语言（例如C和#C）竞争的顶级编程语言之一。通常是Java编程语言，在各种操作系统（例如Android，Windows，Linux和Mac）上的软件和游戏开发中高度使用。这个功能强大的Java编程语言套件具有最新更新，在其套件中添加了其他功能，可以帮助开发Java开发人员和程序员。这个大型套件还可以完全测试并运行您的扩展软件.
甲骨文Java Development Kit（JDK）是整个Java的核心，包括了Java运行环境、Java开发工具包和Java基础类库源代码。JDK作为JAVA开发环境，是运行JAVA程序不可缺少的环境，不管是做JAVA开发还是安卓开发，都必须在系统安装JDK。小到小型设备，大到智慧城市，Java的贡献力量是其他任何技术无可比拟的。
日志：
oracle.com/technetwork/java/javase/14all-relnotes-5809668.html
2020年3月17日 Java 14 正式版发布了！
特性一：全新的Switch表达式：通过扩展原来的Switch来简化编码，现在它既可以用作语句，也可以用作表达式。在JDK 12和JDK 13中进行了预览之后，预计Switch表达式将成为JDK 14中的一个永久特性。Switch表达式还准备在Switch中使用模式匹配，允许开发人员有条件地从对象中提取组件。Oracle在9月17日表示，switch表达式有望在Java开发工具包14 (JDK 14)中得到最终版。
特性二：在http://openjdk.java.net上发布的JDK 14的一个JDK增强建议(JEP)中，提及将升级Java的映射字节缓冲区以支持非易失性内存。
在switch表达式正式到来之前，非易失性映射字节缓冲区(non-volatile mapped byte buffers)仍然是官方提出的针对JDK 14的惟一特性。非易失性映射字节缓冲区将添加新的特定于jdk的文件映射模式，允许使用FileChannel API创建引用非易失性内存(NVM)的MappedByteBuffer实例。Intel 的傲腾内存估计要笑出声啦
安装说明
1、下载并解压，双击jdk-14_windows-x64_bin.exe运行安装，点击下一步
2、安装位置，点击下一步
3、可以点击后续步骤来学习使用JDK
检查JDK环境是否配置成功命令：
CMD命令提示符输入 java -version
JDK14新版说明
一、JDK 14的新增功能-新功能和增强功能
本节描述Java SE 14和JDK 14中的一些增强功能。在某些情况下，描述提供了指向有关问题或更改的其他详细信息的链接。此处描述的API是Oracle JDK随附的API。它包括Java SE 14平台的完整实现以及支持开发，调试和监视Java应用程序的其他Java API。有关Java SE 14和JDK 14中的重要增强功能和新功能的另一个信息来源是Java SE 14（JSR 389）平台规范，它记录了Java SE 13和Java SE 14之间对规范所做的更改。该文档包括对这些新功能和增强功能的描述，这些新功能和增强功能也是对规范的更改。这些描述还确定了迁移到JDK 14时可能遇到的潜在兼容性问题。
1、核心库
➜ 会计货币格式支持
可以通过NumberFormat.getCurrencyInstance(Locale)使用“ u-cf-account” Unicode区域设置扩展名来获得具有记帐样式的货币格式实例，其中金额在某些区域设置中用括号表示。例如，在中Locale.US，它将格式化为“ ($3.27)”而不是“ -$3.27”。有关更多信息，请参阅CLDR的记帐货币格式样式。
参见JDK-8215181
2、核心库/java.lang
➜ JEP 359记录（预览版）
在JDK 14中，“ 记录（JEP 359）”预览功能添加了一个新类java.lang.Record。该java.lang软件包是按需隐式导入的import java.lang.*。如果现有源文件中的代码按需导入某些其他程序包，例如，import com.myapp.*;并且该其他程序包声明了一个名为的类型Record，则引用该类型的现有源文件中的代码将不进行更改而不会编译。要编译代码，请Record使用单类型导入（例如）导入其他包的类型import com.myapp.Record;。
参见JDK-8222777
3、核心库/java.nio
➜ 阐明ReadableByteChannel.read（）的规范和相关方法
的规格DatagramChannel.receive()，FileChannel.read(ByteBuffer,long)，ReadableByteChannel.read()，和ScatteringByteChannel.read()方法已经在此版本已经更新到指定的IllegalArgumentException是，如果（任何）缓冲区参数（S）是只读的抛出。此更改仅调整规范以匹配现有的长期行为。
参见JDK-8164993
4、热点/ gc
➜ JEP 365 ZGC在Windows
Z垃圾收集器（ZGC）现在可以在Windows上作为实验功能使用。要启用它，请使用JVM标志-XX:+UnlockExperimentalVMOptions -XX:+UseZGC。有关更多信息，请参见Windows上的JEP 365：ZGC。
参见JDK-8232364
5、热点/ gc
➜ JEP 364 ZGC在MacOS
Z垃圾收集器（ZGC）现在可作为macOS上的实验功能使用。要启用它，请使用JVM标志-XX:+UnlockExperimentalVMOptions -XX:+UseZGC。有关更多信息，请参见macOS上的JEP 364：ZGC。
参见JDK-8229358
6、热点/ gc
➜ 并行GC改进
并行GC已采用与其他收集器相同的任务管理机制来调度并行任务。这可能会显着提高性能。由于这一变化，以下产品标志已过时： -XX:BindGCTaskThreadsToCPUs，-XX:UseGCTaskAffinity，和-XX:GCTaskTimeStampEntries。
参见JDK-8224666
7、热点/ gc
➜G1的 JEP 345 NUMA感知内存分配
G1垃圾收集器现在尝试跨垃圾收集在年轻一代的同一NUMA节点上分配并保留对象。这类似于并行GC NUMA意识。
G1尝试使用严格的交错在所有可用的NUMA节点上均匀分配Humongous和Old区域。从年轻一代复制到老一代的对象的放置是随机的。
这些新的NUMA感知内存分配试探法通过使用-XX:+UseNUMA命令行选项自动启用。有关更多信息，请参见 JEP 345：G1的NUMA感知内存分配。
参见JDK-8210473
8、安全库/java.security
➜ 在TLS，证书路径弱命名曲线，并签署JAR默认情况下禁用
默认情况下，通过将弱命名曲线添加到以下disabledAlgorithms安全属性来禁用它们：“ jdk.tls.disabledAlgorithms”，“ jdk.certpath.disabledAlgorithms”和“ jdk.jar.disabledAlgorithms”。下面列出了命名曲线。
如果要禁用47条弱命名曲线，则向每个disabledAlgorithms属性添加单独的命名曲线将不堪重负。为了减轻这种情况，实现了一个新的安全属性“ jdk.disabled.namedCurves”，该disabledAlgorithms属性可以列出所有属性共有的命名曲线。要在属性中使用新disabledAlgorithms属性，请在完整属性名称之前加上关键字include。用户仍然可以将单独的命名曲线添加到disabledAlgorithms与此新属性分开的属性。这些属性中不能包含其他disabledAlgorithms属性。
要恢复命名曲线，请include jdk.disabled.namedCurves从特定或所有 disabledAlgorithms安全性属性中删除。要恢复一条或多条曲线，请从jdk.disabled.namedCurves属性中删除特定的命名曲线。
曲线被禁用通过jdk.disabled.namedCurves包括以下：secp112r1，secp112r2，secp128r1，secp128r2，secp160k1，secp160r1，secp160r2，secp192k1，secp192r1，secp224k1，secp224r1，secp256k1，sect113r1，sect113r2，sect131r1，sect131r2，sect163k1，sect163r1，sect163r2，sect193r1，sect193r2 ，sect233k1，sect233r1，sect239k1，sect283k1，sect283r1，sect409k1，sect409r1，sect571k1，sect571r1，X9.62 c2tnb191v1，X9.62 c2tnb191v2，X9.62 c2t2b2v2，X9.62 c2tnb1919， .62 c2tnb359v1，X9.62 c2tnb431r1，X9.62 prime192v2，X9.62 prime192v3，X9.62 prime239v1，X9.62 prime239v2，X9.62 prime239v3，brainpoolP256r1，brainpoolP320r1，brainpoolP384r1，brainpoolP512r1
保持启用的曲线为：secp256r1，secp384r1，secp521r1，X25519，X448
参见JDK-8233228
9、security-libs / javax.xml.crypto
➜Apache Santuario库已更新至版本2.1.4
Apache Santuario库已升级到版本2.1.4。结果，com.sun.org.apache.xml.internal.security.parser.pool-size引入了新的系统属性。
这个新的系统属性设置DocumentBuilder处理XML签名时使用的内部缓存的池大小。该函数等效org.apache.xml.security.parser.pool-size于Apache Santuario中使用的系统属性，并且具有相同的默认值20。
参见JDK-8231507
10、工具/ javac
➜ 允许默认情况下调用可发现的javac插件
如果未javac在从命令行传递的选项或optionsAPI调用的参数中显式启动，则默认情况下可以选择默认启动javac“ plugins” 。通过实现Plugin.isDefault()return 方法可以启用此行为true。
参见JDK-8234211
11、xml / jaxp
SA SAX ContentHandler的用于处理XML声明的新方法
declaration已添加新方法SAX ContentHandler以接收XML声明的通知。通过实现此方法，应用程序可以完全按照输入文档中的声明接收版本，编码和独立属性的值。
二、删除的功能和选项
本节描述了Java SE 14和JDK 14中删除的API，功能和选项。此处描述的API是Oracle JDK随附的API。它包括Java SE 14平台的完整实现以及支持开发，调试和监视Java应用程序的其他Java API。有关Java SE 14和JDK 14中重要增强功能和新功能的另一个信息来源是Java SE 14（JSR 389）平台规范，该文档记录了对Java SE 13和Java SE 14之间的规范所做的更改。此处未描述的已删除API和功能。下面的描述还可能标识在迁移到JDK 14时可能遇到的潜在兼容性问题。在JDK 14中关闭的CSR列表已批准JDK 14的CSR。
1、核心库/java.nio.charsets
➜ sun.nio.cs.map系统属性去除
sun.nio.cs.mapJDK 1.4.1中添加的系统属性已被删除。它为应用程序提供了帮助，以帮助从旧的定义（Shift_JIS相当于MS Windows代码页932）迁移到IANA定义的定义。使用mapping属性的应用程序将需要根据其需要指定正确的字符集名称。
参见JDK-8229960
2、部署
mov 删除netscape.javascript.JSObjectgetWindow方法
过时的netscape.javascript.JSObject::getWindow方法已被删除。在JDK 9中不推荐使用此方法。从JDK 11开始，不再有使用此方法的有用方法。它总是返回null。
参见JDK-8222563
3、热点/ gc
EP JEP 363删除并发标记和扫描（CMS）垃圾收集器
CMS垃圾收集器已被删除。-XX:UseConcMarkSweepGC和别名-Xconcgc，-Xnoconcgc以及所有CMS特定选项（太多，无法列出）都已废弃。有关更多信息，请参见JEP 363：删除并发标记扫描（CMS）垃圾收集器。
参见JDK-8229049
4、安全库/java.security
➜ 删除了不推荐使用的java.security.acl API
不推荐使用的java.security.aclAPI已被删除。这包括在该包以下类：Acl，AclEntry，AclNotFoundException，Group，LastOwnerException，NotOwnerException，Owner，和Permission。
参见JDK-8191138
5、安全库/java.security
➜ 删除默认的keytool -keyalg值
keytool -genkeypair和keytool -genseckey命令的默认密钥算法已被删除。现在，您必须-keyalg在使用-genkeypair或-genseckey命令时通过包含选项来指定密钥算法。如果-keyalg未指定该选项，keytool将终止并显示错误消息：“必须指定-keyalg选项”。
参见JDK-8214024
6、工具/罐子
EP JEP 367删除Pack200工具和API
JDK 5.0中添加的pack200和unpack200工具已被删除。类java.util.jar.Pack200和接口java.util.jar.Pack200.Packer，并java.util.jar.Pack200.Unpacker也已被删除。不推荐在Java SE 11中删除这些工具和API，并明确打算在将来的版本中删除它们。此外，在该jar工具中，nto 的子选项jar c已被删除。有关更多信息，请参见JEP 367：删除Pack200工具和API。
三、不推荐使用的功能和选项
有关Java SE 14和JDK 14中不推荐使用的API，功能和选项的其他信息，包括：
“ 不推荐使用的API”页面可标识所有不推荐使用的API，包括Java SE 14中不推荐使用的API。
该爪哇SE 14（JSR 389）规范文档改变到Java SE 13和Java SE 14，其包括已弃用的API的识别和特征不再赘述之间所订的规格。
JEP 277：增强的弃用提供了弃用策略的详细说明。您应该了解本文档中描述的更新策略。
您应该了解这些文档中的内容以及此发行说明页面中描述的项目。
弃用的API的描述可能包括到的废弃警告引用forRemoval=true和forRemoval=false。该forRemoval=true文本表示弃用的API可能会从下一个主要版本中删除。该forRemoval=false文本表示弃用的API预计不会从下一个主要版本中删除，但可能会在以后的某个版本中删除。
下面的描述还标识了在迁移到JDK 14时可能遇到的潜在兼容性问题。有关在JDK 14中关闭的CSR列表，请参阅JDK 14批准的CSR。
1、核心库/java.lang
➜ 不建议使用线程挂起/继续删除
下面的方法中涉及的线程挂起java.lang.Thread，并java.lang.ThreadGroup已在本版本中晚期弃用：
Thread.suspend()
Thread.resume()
ThreadGroup.suspend()
ThreadGroup.resume()
ThreadGroup.allowThreadSuspension(boolean)
这些方法将在将来的版本中删除。
参见JDK-8231602
2、热点/ gc
➜ JEP 366弃用ParallelScavenge + SerialOld GC组合
ParallelScavenge + SerialOld垃圾收集器组合已被弃用。任何UseParallelOldGC用于启用此垃圾回收算法组合的命令行选项的使用，都会引起弃用警告。
嵌入式替换是通过-XX:+UseParallelGC在命令行上使用ParallelScavenge + ParallelOld垃圾收集器 。
有关更多信息，请参见JEP 366：弃用ParallelScavenge + SerialOld GC组合。
参见JDK-8233301
3、security-libs / javax.crypto
➜ 已过时的旧椭圆曲线的去除
SunEC提供者支持的以下命名椭圆曲线已弃用：
brainpoolP256r1，brainpoolP320r1，brainpoolP384r1，brainpoolP512r1，secp112r1，secp112r2，secp128r1，secp128r2，secp160k1，secp160r1，secp160r2，secp192k1，secp192r1，secp224k1，secp224r1，secp256k1，sect113r1，sect113r2，sect131r1，sect131r2，sect163k1，sect163r1，sect163r2，sect193r1，sect193r2， sect233k1，sect233r1，sect239k1，sect283k1，sect283r1，sect409k1，sect409r1，sect571k1，sect571r1，X9.62 c2tnb191v1，X9.62 c2tnb191v2，X9.62 c2t2b2n2，X9.6t2c2t2b2n1、2 62 c2tnb359v1，X9.62 c2tnb431r1，X9.62 prime192v2，X9.62 prime192v3，X9.62 prime239v1，X9.62 prime239v2，X9.62 prime239v3
这些曲线的实现旨在在后续的JDK版本中删除。一小部分可以用更现代的实现方式代替。
参见JDK-8234924
4、security-libs / javax.crypto
➜ 弃用的OracleUcrypto JCE提供去除
jdk.crypto.ucrypto不推荐使用OracleUcrypto JCE Provider及其包含的模块，并且可能在JDK的未来版本中将其删除。有关更多信息，请参见JEP 362。
五、其他注意事项
以下说明描述了此版本的其他更改和信息。在某些情况下，以下描述提供了指向有关问题或更改的其他详细信息的链接。
1、客户端库
mac macOS暗模式下的文本可见性问题
据报道，在macOS上，针对暗模式的许多错误需要JavaRuntimeSupport框架（JRS）的修复。已向Apple提出问题：
FB6798883：JavaRuntimeSupport.framework在黑暗模式下无法正常工作
有关此错误引起的问题的示例，请参见JDK-8231386和JDK-8228555。
参见JDK-8228555
2、核心库/java.io：序列化
➜ 更好的串行过滤器处理
该jdk.serialFilter系统属性只能在命令行中进行设置。如果尚未在命令行上设置过滤器，则可以使用进行设置java.io.ObjectInputFilter.Config.setSerialFilter。将jdk.serialFilter设置为java.lang.System.setProperty无效。
JDK-8231422（非公开）
3、核心库/java.lang
➜ 线程中断状态始终可用
该规范java.lang.Thread::interrupt允许实现仅跟踪活动线程的中断状态，并且以前就是这种情况。从此版本开始，a的中断状态Thread始终可用，并且如果您在线程t启动之前或终止之后中断线程，查询t.isInterrupted()将返回true。
参见JDK-8229516
4、核心库/java.lang
➜ 改为无条件Thread.countStackFrames抛出UnsupportedOperationException异常
最终不推荐使用的方法Thread.countStackFrames已在此发行版中更改为无条件抛出UnsupportedOperationException。
在将来的版本中将删除此方法。
参见JDK-8205132
5、core-libs / java.lang.invoke
➜ MethodTypefromMethodDescriptorString需要“getClassLoader”权限
MethodType::fromMethodDescriptorString在此版本中已更改。存在安全管理器且loader参数为null时，它将执行RuntimePermission（“ getClassLoader”）安全许可权检查。此检查确保允许访问系统类加载器。
如果拒绝对系统类加载器的访问，则调用的现有代码MethodType.fromMethodDescriptorString(desc, null)可能会获得 SecurityException。必须将安全策略配置为授予权限。在没有安全管理器或非空加载器的情况下运行的应用程序不受此更改的影响。
参见JDK-8229785
6、core-libs / java.lang.invoke
➜ MethodHandlesprivateLookupIn需要私人查询方式
MethodHandles::privateLookupIn已经变了。在此版本中，调用者Lookup必须同时具有PRIVATE和MODULE访问权限，因为打算MODULE单独使用共享模块内访问权限的应用程序会不经意间也共享对其自身模块的深刻反映。另外，如果Lookup对象是通过一个模块创建Lookup::in或MethodHandles::privateLookupIn从一个模块传送到另一个模块，则该MODULE模式将被放弃。换句话说，MethodHandles::privateLookupIn要求调用者查找对象必须由成员从调用者的模块创建，并且不能由跨模块的传送产生。
例如，L通过调用创建的查找对象MethodHandles.privateLookupIn(C.class, caller)（其中C是模块M1中的类，而调用者的查找类在模块M0中）可以在以下情况下访问模块M2中公共类D的公共成员：
M0和M1读取M2，并且
D在从M2导出到至少M0和M1的包中。
如果M0可以访问M2中的D，但M1不能访问D，则查找对象L将无法在此版本中查找D中的成员，但在以前的版本中会成功。
参见JDK-8173978
7、core-libs / java.lang.invoke
➜ Lookupin抛出：IllegalArgumentException -如果requestedLookupClass是基本类型或数组类
java.lang.invoke.MethodHandles.Lookup::inIllegalArgumentException如果给定的requestedLookupClass是原始类型，void或数组类，则抛出该方法。甲Lookup对象从不打算允许查找类基本类型，无效或数组类的。因此，Lookup::inJava SE 14已修复的规范。
参见JDK-8173975
8、core-libs / java.lang.invoke
➜ MethodHandlesprivateLookupIn可能不会产生一个查找具有完全访问权限
在此版本中Lookup产生的对象MethodHandles::privateLookupIn可能没有完全特权访问权。一个Lookup是拥有私人和模块访问模式被认为具有可与被测试完全权限存取Lookup::hasFullPrivilegeAccess方法。在以前的版本中，Lookupfrom 的返回值MethodHandles::privateLookupIn可用于查找对调用者敏感的方法。在Java SE 14中，如果a Lookup不具有完全特权访问权限（即使它具有私有访问模式），则它可能无法查找对调用者敏感的方法。
参见JDK-8233527
9、核心库/java.net
➜ DatagramSocket.send和MulticastSocket.send抛出IllegalArgumentException当套接字没有连接和数据包不包含地址
如果套接字未连接且没有套接字地址，send则由DatagramSocket和定义的方法MulticastSocket已更改为抛出。在进行此更改之前，这些方法都引发了。IllegalArgumentExceptionDatagramPacketNullPointerException
参见JDK-8233141
10、核心库/java.net
➜MulticastSocket getOption（IP_MULTICAST_IF）未设置传出接口时返回null
该MulticastSocket方法getOption已更改为符合中描述的行为StandardSocketOptions.IP_MULTICAST_IF。如果没有设置接口，MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_IF)现在返回null。
参见JDK-8233307
11、核心库/java.net
➜ MulticastSocket上getOption /的SetOption为IP_MULTICAST_LOOP个符合随着StandardSocketOptions.IP_MULTICAST_LOOP规范的行为
该MulticastSocket方法getOption和setOption已更改以符合所描述的行为StandardSocketOptions.IP_MULTICAST_LOOP规范。MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_LOOP)现在，如果启用了环回模式，则返回true。设置MulticastSocket.setOption(StandardSocketOptions.IP_MULTICAST_LOOP, true)启用回送模式。
参见JDK-8233296
12、核心库/java.net
➜ 针对IPv6文字和未解析地址的InetSocketAddress.toString格式更改
InetSocketAddress::toString关于IPv6地址的处理方法已得到改进。现在，该实现将IPv6文字括在方括号中，该文字符合RFC2732中概述的规范。
此外，未解析地址的字符串格式已更改。该方法现在用令牌表示IP文字<unresolved>，例如：foo/<unresolved>:80代替 foo:80。
参见JDK-8225499
13、核心库/java.nio
➜DatagramChannel.disconnect 可能会使通道的套接字处于未指定状态
DatagramChannel此发行版中的实现已更新，因此该disconnect方法尝试解决Linux内核行为，该行为在解除关联后将本地端口恢复为0。当a DatagramChannel最初绑定到临时端口，连接（通过调用其connect方法）然后断开连接（通过调用其方法）时，就会出现此问题disconnect。中的解决方法DatagramChannel::disconnect是尝试将通道的套接字重新绑定到其原始端口。通常这会成功，但是如果失败，IOException则会抛出一个。此解决方法已在DatagramSocket多个发行版的实现中使用。
作为此更改的一部分，javadocfor DatagramChannel::disconnect进行了API注释更新，以明确表明IOException可能会使通道的套接字处于未指定状态。API注释还强烈建议disconnect失败时关闭通道。
参见JDK-8231260
14、核心库/java.rmi
➜ 改善注册表支持
的java.rmi.Remote含有方法标记接口识别接口，其可以远程通过使用下面的说明书中被调用：
在接口中直接或间接扩展的java.rmi.Remote方法可以远程调用
在接口中定义的不Remote直接或间接扩展的方法不能远程调用
这会影响java.rmi.registry.Registry和其他任何远程对象中的远程对象。
JDK-8230967（非公开）
15、核心库/java.text
➜ 多个支撑在CompactNumberFormat
java.text.CompactNumberFormat现在能够处理复数形式。例如，数字2,000,000被格式化为"2 Millionen"在LONG风格，而1,000,000以"1 Million"德国语言。
参见JDK-8222756
16、核心库/java.util:i18n
➜ 升级CLDR到V36
基于Unicode Consortium的CLDR的区域设置数据已升级到其版本36。有关详细的区域设置数据更改，请参阅Unicode Consortium的CLDR发行说明：
http://cldr.unicode.org/index/downloads/cldr-36
参见JDK-8231273
17、核心库/javax.lang.model
➜ ExecutableElement.getReceiverType改为返回NoType在救父空
规范ExecutableElement.getReceiverType要求NOTYPE在未定义接收器类型时返回它。NOTYPE在这种情况下，实现已更改为返回，而不是返回null。
参见JDK-8222369
18、核心库/javax.naming
➜ DnsClient TCP套接字超时
com.sun.jndi.dns.timeout.initialJNDI DNS提供程序实现的属性的语义已被修改。现在，此超时值统一适用于UDP和TCP查询。以前，它仅适用于UDP查询。
参见JDK-8228580
19、热点/编译器
➜ 已关闭AOT由默认的和更改相关的标志实验
的默认值UseAOT已从更改enabled为disabled，并且以下与AOT支持相关的标志已更改为实验性：
UseAOT
PrintAOT
AOTLibrary
参见JDK-8227439
20、热点/运行时
➜ 添加了-XX + AdjustStackSizeForTLS标志
该glibc库在新创建的线程的堆栈中分配了一些线程本地存储（TLS），所剩下的堆栈少于该线程完成其工作所需的堆栈。对于具有小堆栈大小的线程，这尤其是个问题。这是一个众所周知的glibc问题的继承性问题，“带有大TLS段的程序失败” [0]，并且已在Java应用程序中观察到。在报告的一个JVM故障实例中，问题表现为StackOverflowError进程收割线程上的，该线程的堆栈大小较小。该java.lang.Thread构造使用户能够指定堆栈大小为一个新的线程。当指定的大小太小而无法容纳堆栈上的TLS块时，创建的线程可能会遇到TLS问题。
在JDK 8中，jdk.lang.processReaperUseDefaultStackSize引入了系统属性来解决仅针对收割线程的TLS问题。设置该属性可使收割线程具有更大的堆栈大小。
为了解决所有线程的问题，在Java中实现了一种通用的解决方法，该方法可调整TLS的线程堆栈大小。可以使用AdjustStackSizeForTLS命令行选项启用它：
-XX:+AdjustStackSizeForTLS
创建新线程时，如果AdjustStackSizeForTLS为true，则将静态TLS区域大小添加到用户请求的堆栈大小。AdjustStackSizeForTLS默认情况下处于禁用状态。
参考：[0] 错误11787-具有较大TLS段的程序失败
参见JDK-8225035
21、热点/运行时
N NullPointerExceptions中的详细消息
可以使用一个新选项来提供更多有用的NullPointerException消息：
-XX:+ShowCodeDetailsInExceptionMessages
如果设置了该选项，则在遇到空指针时，JVM会分析程序以确定是哪个引用null，然后作为的一部分提供详细信息NullPointerException.getMessage()。除了异常消息，还返回方法，文件名和行号。
默认情况下，此选项是禁用的。
参见JDK-8218628
22、热点/运行时
➜ CDS行为改变与不存在的文件在创建归档
在JDK 14中，当处理类路径中不存在的文件时，CDS运行时类路径验证现在更为宽容。
在CDS归档转储时，将自动删除类路径中所有不存在的元素。例如，如果命令是：
java -cp nosuchfile.jar:hello.jar -Xshare:dump \
-XX:SharedClassListFile=hello.classlist \
-XX:SharedArchiveFile=hello.jsa
删除不存在的元素后，记录在中的类路径hello.jsa变为hello.jar。
同样，在运行时，当加载CDS存档时，将忽略类路径中所有不存在的元素。在前面的示例中，以下所有命令将成功加载存档：
（1）
java -cp nosuchfile.jar:hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \
Hello
（2）
java -cp hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \
Hello
（3）
java -cp alsonosuchfile.jar:hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \
Hello
在JDK 13和更早版本中，仅允许（1），而（2）和（3）会触发错误。
参见JDK-8227370
23、安全库/java.security
Trust 可信TLS服务器证书需要完全匹配
TLS服务器证书必须与客户端上的受信任证书完全匹配，以便在建立TLS连接时被信任。
JDK-8227758（非公开）
24、安全库/java.security
➜ 对信任锚证书新的检查
添加了新的检查，以确保信任锚是CA证书并包含适当的扩展名。信任锚用于验证TLS和签名代码中使用的证书链。信任锚证书必须包含“基本约束”扩展，且cA字段设置为true。另外，如果它们包括“密钥用法”扩展，则必须将keyCertSign位置1。
jdk.security.allowNonCaAnchor如有必要，引入了一个名为的新系统属性来恢复以前的行为。如果该属性设置为空String或“ true”（不区分大小写），则信任锚证书如果没有适当的CA扩展名，则可以使用它们。
如果未设置，则此属性的默认值为“ false”。
请注意，该属性不适用于X.509 v1证书（因为它们不支持扩展名）。
JDK实现当前使用此属性。不保证其他Java SE实现也支持它。
JDK-8230318（非公开）
25、安全库/java.security
➜ 添加了LuxTrust Global Root 2证书
以下根证书已添加到cacerts信任库中：
+ LuxTrust
+ luxtrustglobalroot2ca
DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU
参见JDK-8232019
26、安全库/java.security
➜ 添加了4个Amazon Root CA证书
以下根证书已添加到cacerts信任库中：
+ Amazon
+ amazonrootca1
DN: CN=Amazon Root CA 1, O=Amazon, C=US
+ amazonrootca2
DN: CN=Amazon Root CA 2, O=Amazon, C=US
+ amazonrootca3
DN: CN=Amazon Root CA 3, O=Amazon, C=US
+ amazonrootca4
DN: CN=Amazon Root CA 4, O=Amazon, C=US
参见JDK-8233223
27、security-libs / javax.crypto
➜ 保护javax.crypto.Cipher中的构造函数抛出IAE非空参数无效
如果提供的参数对于构造对象无效，则将的受保护构造函数javax.crypto.Cipher更改为throw 。如果provider参数为null，则构造函数将像以前一样抛出。现在，这两个异常都记录在受保护构造函数的javadoc规范中。IllegalArgumentExceptionNullPointerExceptionCipherNullPointerException
参见JDK-8233016
28、security-libs / javax.crypto
➜ SunJCE提供抛出抛出：NoSuchAlgorithmException为AES / GCM / PKCS5Padding
在此版本之前，Cipher当调用者请求“ AES / GCM / PKCS5Padding”时，SunJCE提供程序错误地返回了“ AES / GCM / NoPadding”转换的实例。现在，NoSuchAlgorithmException当请求“ AES / GCM / PKCS5Padding”时，SunJCE提供程序将引发。如果您受到此问题的影响，解决方法是改用“ AES / GCM / NoPadding”。
参见JDK-8180392
29、security-libs / javax.net.ssl
➜ 从默认启用的TLS协议中删除了SSLv2Hello和SSLv3
SSLv2Hello和SSLv3已从默认启用的TLS协议中删除。
本次更新后，如果在SSLv3从去除jdk.tls.disabledAlgorithms安全特性，SSLSocket.getEnabledProtocols()，SSLServerSocket.getEnabledProtocols()，SSLEngine.getEnabledProtocols()和SSLParameters.getProtocols()的API将返回“TLSv1.3，TLSv1.2工作，TLSv1.1，使用TLSv1”。该列表中不会返回“ SSLv3”。
如果客户端或服务器仍然需要使用SSLv3的协议，他们可以通过启用它通过这样做jdk.tls.client.protocols或jdk.tls.server.protocols系统属性，或使用SSLSocket.setEnabledProtocols()，SSLServerSocket.setEnabledProtocols()以及SSLEngine.setEnabledProtocols()API的。
参见JDK-8190492
30、安全库/javax.security
➜ DelegationPermission允许创建一个实例Thows NPE上等于呼叫
当DelegationPermission对象被创建和principals参数不包含一对主体的，一个IllegalArgumentException现在抛出。
参见JDK-8231196
31、工具/ javac
➜ 的toString（）上的注释对象是核心映像和javac之间是一致的
javac通过批注处理，核心反射和都具有表示批注的对象。toString两种注释对象的输出现在遵循相同的约定。这些约定允许在源代码中使用输出。
参见JDK-8164819
32、xml / javax.xml.transform
➜ 默认ErrorListener不再向控制台报告警告和错误
在此版本之前，该javax.xml.transform.ErrorListener规范定义默认的ErrorListener实现将警告和错误报告给System.err，并且System.out在某些情况下。从此版本开始，此要求已被删除，默认设置ErrorListener现在不对警告和可恢复的错误采取任何措施；并在发生严重错误的情况下抛出TransformerException。
建议应用程序始终对其ErrorListener进行注册，以确保正确处理警告和错误。
六、Oracle JDK与Oracle OpenJDK之间的差异
尽管我们已经声明了使OpenJDK和Oracle JDK二进制文件彼此尽可能接近的目标，但至少对于JDK 13，这两个选项之间仍然存在一些差异。
当前的区别是：
Oracle JDK提供了“安装程序”（msi，rpm，deb等），它们不仅将JDK二进制文件放置在系统中，而且还包含更新规则，并且在某些情况下会处理一些常用配置，例如设置常用环境变量（例如JAVA_HOME in Windows）并建立文件关联（例如，使用Java启动.jar文件）。OpenJDK仅作为压缩存档（tar.gz或.zip）提供。
javac的 -release释放值9和10表现不同。Oracle JDK二进制文件包括未添加到OpenJDK二进制文件中的API，例如javafx，资源管理和（JDK 11之前的更改）JFR API。
使用情况记录仅在Oracle JDK中可用。
Oracle JDK要求使用Java密码学扩展（JCE）代码签名证书对第三方加密提供程序进行签名。OpenJDK继续允许使用未签名的第三方加密提供程序。
java -version的输出是不同的。Oracle JDK返回java，并包含Oracle特定的标识符。OpenJDK返回OpenJDK，并且不包含Oracle特定的标识符。
Oracle JDK是根据OTN许可发行的。OpenJDK在GPLv2wCP下发布。因此，每个随附的许可证文件将有所不同。
Oracle JDK根据FreeType许可证分发FreeType，而OpenJDK按照GPLv2分发FreeType。因此，\ legal \ java.desktop \ freetype.md的内容是不同的。
Oracle JDK具有Java cup和Steam图标，而OpenJDK具有Duke图标。
Oracle JDK源代码包括“ ORACLE专有/机密。使用须遵守许可条款。” 与OpenJDK一起分发的源代码引用了GPL许可条款。
