我需要哪个Java包？
软件开发人员：JDK（Java SE Development Kit）。对于Java开发人员。包括完整的JRE以及用于开发，调试和监视Java应用程序的工具。
在服务器上运行应用程序的管理员：服务器JRE（服务器Java运行时环境）用于在服务器上部署Java应用程序。包括用于JVM监视的工具和服务器应用程序通常需要的工具，但不包括浏览器集成（Java插件），自动更新和安装程序。 
最终用户在桌面上运行Java：JRE :( Java运行时环境）。涵盖了大多数最终用户的需求。包含在系统上运行Java应用程序所需的所有内容
重要的变化和信息
以下是此版本的一些重要更改和信息。在某些情况下，这些发行说明中提供了有关下述更改的其他详细信息。
-
Applet和Web Start应用程序所需的部署堆栈在JDK 9中已弃用，并已在JDK 11中删除。
-
如果没有部署堆栈，则已从支持的JDK 11配置列表中删除了支持的浏览器的整个部分。
-
在Windows和macOS上可用于JRE安装的自动更新不再可用。
-
在Windows和macOS中，在以前版本中安装JDK可选择安装JRE。在JDK 11中，这不再是一个选项。
-
在此版本中，不再提供JRE或Server JRE。仅提供JDK。用户可以使用jlink创建较小的自定义运行时。
-
JDK中不再包含JavaFX。它现在可以从openjfx.io单独下载。
-
Oracle JDK不再包含JDK 7,8,9和10中提供的Java Mission Control。它现在是一个单独的下载。
-
以前的版本被翻译成英语，日语和简体中文以及法语，德语，意大利语，韩语，葡萄牙语（巴西），西班牙语和瑞典语。但是，在JDK 11及更高版本中，不再提供法语，德语，意大利语，韩语，葡萄牙语（巴西），西班牙语和瑞典语翻译。
-
Windows的更新包装格式已从更改tar.gz为.zip，这在Windows操作系统中更常见。
-
已更新的macOS包格式已更改.app为.dmg，这更符合macOS的标准。
JDK 11中的新功能 - 新功能和增强功能
以下注释描述了Java SE 11和JDK 11中的一些增强功能。这些描述可能包含指向更详细描述增强功能的其他文档的链接。此处描述的API是随Oracle JDK提供的API。它包括Java SE 11平台的完整实现和其他Java API，以支持Java应用程序的开发，调试和监视。关于Java SE 11和JDK 11中重要增强功能和新功能的另一个信息来源是Java SE 11（18.9）（JSR 384）平台规范，记录了Java SE 10和Java SE 11之间对规范的更改。本文档包括对规范进行更改的那些新功能和增强功能的描述。以下描述还可能标识迁移到JDK 11时可能遇到的潜在兼容性问题。
核心库/ java.lang中➜ JEP 327的Unicode 10
升级现有平台API以支持Unicode标准版本10.0（JEP 327：Unicode 10）。
JDK 11版本包括对Unicode 10.0.0的支持。自从支持Unicode 8.0.0的JDK 10发布以来，JDK 11结合了Unicode 9.0.0和10.0.0版本，包括：
16,018个新字符包含以下重要内容：
-
新4K电视标准的19个符号
-
比特币的标志
-
128个表情符号字符
10个新脚本：
-
Adlam
-
Bhaiksuki
-
童话
-
纽瓦
-
奥沙
-
西夏文
-
Masaram Gondi
-
女书
-
Soyombo
-
Zanabazar广场
18个新块，包括10个用于上面列出的新脚本的块和8个用于以下现有脚本的块：
-
Cyrillic Extended-C
-
蒙古语补编
-
表意符号和标点符号
-
西夏组件
-
Glagolitic补充剂
-
叙利亚补充
-
假名扩展-A
-
CJK Extension F.
核心库/ java.net➜ JEP 321 HTTP客户端（标准）
通过JEP 110标准化JDK 9中引入的孵化HTTP客户端API，并在JDK 10（JEP 321）中进行更新。
HTTP客户端已在Java 11中标准化。作为此工作的一部分，位于jdk.incubator.http包中的先前孵化的API 已被删除。至少，jdk.incubator.http需要更新使用包中类型的代码以从标准包名称导入HTTP类型，java.net.http.
核心库/ java.util中：收藏➜ 新的Collection.toArray（IntFunction）默认方法
接口toArray(IntFunction)添加了一个新的默认方法java.util.Collection。此方法允许将集合的元素传输到新创建的所需运行时类型的数组。新方法是现有toArray(T[])方法的重载，它将数组实例作为参数。添加重载方法会导致次要源不兼容。以前，表单的代码coll.toArray(null)将始终解析为现有toArray方法。使用新的重载方法，此代码现在不明确，将导致编译时错误。（这只是源不兼容。现有的二进制文件不受影响。）应该更改模糊代码以null转换为所需的数组类型，例如，toArray((Object[])null)或其他一些数组类型。请注意，传递null给任何一个toArray指定方法抛出NullPointerException。
核心库/ java.util中：I18N➜将 区域设置数据更新为Unicode CLDR v33
基于Unicode Consortium的CLDR（公共区域设置数据注册表）的区域设置数据已针对JDK 11进行了更新。补充平面中的本地化数字（例如，印度Chakma脚本中的数字）将替换为ASCII数字，直到JDK-8204092被解析。缅甸语区域的中短时间模式尚未升级。当JDK-8209175得到解决，这些模式也将升级。
有关CLDR版本33的更多详细信息，请参阅http://cldr.unicode.org/index/downloads/cldr-33。
热点/编译➜ 编译器线程的延迟分配
添加了一个新的命令行标志-XX:+UseDynamicNumberOfCompilerThreads来动态控制编译器线程。在分层编译模式（默认情况下处于启用状态）下，无论可用内存和编译请求数如何，VM都会在具有许多CPU的系统上启动大量编译器线程。因为线程即使在空闲时也消耗内存（几乎所有时间都是如此），这导致资源的低效使用。
为解决此问题，已将实现更改为在启动期间仅启动每种类型的一个编译器线程，并动态处理其他线程的启动和关闭。它由新的命令行标志控制，默认情况下处于打开状态：
-XX:+UseDynamicNumberOfCompilerThreads
热点/ GC➜ JEP 333 ZGC一种可扩展低延迟垃圾收集器（试验）
Z垃圾收集器，也称为ZGC，是一个可扩展的低延迟垃圾收集器（JEP 333）。它旨在实现以下目标：
-
暂停时间不超过10毫秒
-
暂停时间不会随堆或实时设置大小而增加
-
处理大小从几百兆到几千兆字节不等的堆
ZGC的核心是并发垃圾收集器，这意味着在Java线程继续执行时，所有繁重的工作（标记，压缩，引用处理，字符串表清理等）都已完成。这极大地限制了垃圾收集对应用程序响应时间的负面影响。
ZGC作为实验性功能包含在内。要启用它，该-XX:+UnlockExperimentalVMOptions选项因此需要与-XX:+UseZGC选项结合使用。
ZGC的这个实验版具有以下限制：
-
它仅适用于Linux / x64。
-
不支持使用压缩的oops和/或压缩的类点。在-XX:+UseCompressedOops和-XX:+UseCompressedClassPointers选项默认情况下禁用。启用它们将不起作用。
-
不支持类卸载。在-XX:+ClassUnloading和-XX:+ClassUnloadingWithConcurrentMark选项默认情况下禁用。启用它们将不起作用。
-
不支持将ZGC与Graal结合使用。
热点/ GC➜ JEP 318ε，无操作垃圾收集器
Epsilon GC是新的实验性无操作垃圾收集器。Epsilon GC仅处理内存分配，并且不实现任何内存回收机制。它对性能测试非常有用，可以与其他GC的成本/收益进行对比。它可用于在测试中方便地断言内存占用和内存压力。在极端情况下，它可能对非常短暂的作业很有用，其中内存回收将在JVM终止时发生，或者在低垃圾应用程序中获得最后一次延迟改进。请参阅JEP 318中有关其使用和权衡的更多讨论。
热点/ JVMTI➜ JEP 331低开销堆纹
提供一种低开销的Java堆分配采样方法，可通过JVMTI（JEP 331）访问。
它旨在实现以下目标：
-
低开销足以在默认情况下持续启用
-
可通过定义明确的编程接口（JVMTI）访问
-
可以对所有分配进行采样（即，不限于在一个特定堆区域中的分配或以特定方式分配的分配）
-
可以以独立于实现的方式定义（即，不依赖于任何特定的GC算法或VM实现）
-
可以提供有关实时和死Java对象的信息
热点/运行➜ JEP 181巢基于角色的访问控制
介绍嵌套，一种访问控制上下文，与Java编程语言中嵌套类型的现有概念一致（JEP-181：基于嵌套的访问控制）。
在Java SE 11中，Java虚拟机支持将类和接口安排到新的访问控制上下文中，称为嵌套。嵌套允许类和接口在逻辑上属于同一代码实体，但是编译为不同的class文件，以访问彼此的private成员，而无需编译器插入可访问性扩展桥接方法。嵌套是Java SE平台的低级机制; Java编程语言的访问控制规则没有变化。javac通过生成新的编译器，在编译Java源代码中的嵌套类和接口时，编译器已更新为使用嵌套class文件属性，用于将顶级类（或接口）及其所有嵌套类和接口放在同一个嵌套中。在检查private构造函数，方法或字段的可访问性时，Java虚拟机已更新为使用这些属性，包括通过核心反射和java.lang.invoke.MethodHandles.LookupAPI。嵌套的成员资格通过新的getNestHost和getNestMembers方法公开java.lang.Class。
由于嵌套成员资格记录在class顶级类或接口（嵌套主机）的class文件中，因此该文件必须在运行时存在，以允许执行访问控制检查。这通常不是问题，因为通常直接使用顶级类或接口。在某些顶级类或接口仅作为嵌套类或接口的持有者并且未使用的代码中，打包工具可能已从class文件库或应用程序的分发中删除该文件。使用基于嵌套的访问控制，如果任何嵌套类或接口需要访问彼此的private成员 - a NoClassDefFoundError或ClassNotFoundException将被抛出，则不再可能忽略顶级类或接口。
安全库/ javax.crypto中➜ 添加了Brainpool EC支持（RFC 5639）
SunEC提供商已得到增强，可支持RFC 5639，椭圆曲线密码术（ECC）Brainpool标准曲线和曲线生成中定义的4个额外Brainpool曲线。可以使用java.security.spec.ECGenParameterSpec标准名称为brainpoolP256r1，brainpoolP320r1，brainpoolP384r1和brainpoolP512r1的对象创建相应的EC域参数。请注意，SunJSSE提供程序尚未得到增强，无法支持这些脑池曲线。
安全库/ javax.crypto中➜ JEP 329 ChaCha20和Poly1305加密算法
实现RFC 7539中指定的ChaCha20和ChaCha20-Poly1305密码.ChaCha20是一种新的流密码，可以替代旧的，不安全的RC4流密码。
那些希望获得ChaCha20流密码实例的人可以使用该方法的算法字符串“ChaCha20” Cipher.getInstance。那些希望在AEAD模式下使用ChaCha20和Poly1305验证器的人可以使用算法字符串“ChaCha20-Poly1305”。有关更多详细信息，请参阅“Java安全标准算法名称”文档。
安全库/ javax.crypto中➜ 增强的KeyStore机制
jceks.key.serialFilter引入了一个名为的新安全属性。如果配置了此过滤器，则JCEKS KeyStore会在对SecretKeyEntry中存储的加密Key对象进行反序列化时使用它。如果未配置或过滤结果为UNDECIDED（例如，没有模式匹配），则查询配置的过滤器jdk.serialFilter。
如果jceks.key.serialFilter还提供了系统属性，它将取代此处定义的安全属性值。
过滤器模式使用与以下格式相同的格式jdk.serialFilter。默认模式允许java.lang.Enum，java.security.KeyRep，java.security.KeyRep$Type，和javax.crypto.spec.SecretKeySpec，但拒绝所有其他人。
存储未序列化为上述类型的SecretKey的客户必须修改过滤器以使密钥可提取。
安全库/ javax.crypto中➜ RSASSA-PSS签名支持添加到SunMSCAPI
RSASSA-PSS签名算法支持已添加到SunMSCAPI提供程序中。
安全库/ javax.net.ssl中➜ JEP 332传输层安全（TLS）1.3
JDK 11版本包括传输层安全性（TLS）1.3规范（RFC 8446）的实现。有关更多详细信息（包括支持的功能列表），请参阅Java安全套接字扩展（JSSE）参考指南文档和JEP 332。
对于TLS 1.3，定义了以下新标准算法名称：
1. TLS协议版本名称：TLSv1.3
2. SSLContext算法名称：TLSv1.3
3. TLS 1.3的TLS密码套件名称：TLS_AES_128_GCM_SHA256，TLS_AES_256_GCM_SHA384
4. X509KeyManager的密钥类型：RSASSA-PSS
5. X509TrustManager的authType：RSASSA-PSS
jdk.tls.keyLimits为TLS 1.3添加了一个新的安全属性。当处理了特定算法的指定数据量时，触发握手后密钥和IV更新以导出新密钥。
添加了一个新的System Property，jdk.tls.server.protocols用于在SunJSSE提供程序的服务器端配置默认启用的协议套件。
请注意，KRB5密码套件实现已从JDK中删除，因为它们不再被认为是安全的。
请注意，TLS 1.3与以前的版本不直接兼容。尽管可以使用向后兼容模式实现TLS 1.3，但在升级到TLS 1.3时仍需要考虑几个兼容性风险：
1. TLS 1.3使用半关闭策略，而TLS 1.2和先前版本使用双工关闭策略。对于依赖于双工关闭策略的应用程序，升级到TLS 1.3时可能存在兼容性问题。
2. signature_algorithms_cert扩展要求使用预定义的签名算法进行证书身份验证。但是，实际上，应用程序可能会使用不受支持的签名算法。
3. TLS 1.3不支持DSA签名算法。如果服务器配置为仅使用DSA证书，则无法升级到TLS 1.3。
4. TLS 1.3支持的密码套件与TLS 1.2和早期版本不同。如果应用程序硬编码不再受支持的密码套件，则可能无法在不修改应用程序代码的情况下使用TLS 1.3。
5. TLS 1.3会话恢复和密钥更新行为与TLS 1.2和先前版本不同。兼容性影响应该是最小的，但如果应用程序依赖于TLS协议的握手细节，则可能存在风险。
如果需要，系统属性jdk.tls.client.protocols和jdk.tls.server.protocols可用于在SunJSSE提供程序中相应地配置默认启用的协议。
安全库/ org.ietf.jgss中：KRB5➜ 支持使用HMAC-SHA2进行AES加密，适用于RFC 8009中定义的Kerberos 5
的Kerberos 5的加密类型aes128-cts-hmac-sha256-128和aes256-cts-hmac-sha384-192在RFC 8009中定义的支持。默认情况下启用这些加密类型。默认的首选顺序是“ aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 des-cbc-crc des-cbc-md5。”
用户可以使用文件中的default_tkt_enctypes和default_tgs_enctypes设置krb5.conf来修改列表。
规格/语言➜ JEP 323：局部变量语法LAMBDA参数
var现在可以在声明lambda表达式的形式参数时使用保留类型名称（[JEP 323]（http://openjdk.java.net/jeps/323））。这建立在Java SE 10 var在声明局部变量时使用的能力的基础上。
使用varlambda表达式的形式参数会导致推断参数的类型，使用与既不存在var也不存在显式类型时相同的规则。自Java SE 8以来，Lambda表达式允许声明其形式参数而不使用显式类型。
如果var用于lambda表达式的任何形式参数，那么它必须用于该lambda表达式的所有形式参数。
工具/发射器➜ JEP 330启动单文件源代码程序
增强java启动程序以运行作为Java源代码的单个文件提供的程序，包括通过“shebang”文件和相关技术从脚本中使用。
删除了功能和选项
本节介绍在Java SE 11和JDK 11中删除的API，功能和选项。此处描述的API是随Oracle JDK提供的API。它包括Java SE 11平台的完整实现和其他Java API，以支持Java应用程序的开发，调试和监视。关于Java SE 11和JDK 11中的重要增强功能和新功能的另一个信息来源是Java SE 11（18.9）（JSR 384）平台规范，该规范记录了Java SE 10和Java SE 11之间对规范的更改。本文档包括已删除的API的标识和此处未描述的功能。下面的描述还可能标识迁移到JDK 11时可能遇到的潜在兼容性问题CSRs已获得JDK 11批准，用于JDK 11中关闭的CSR列表。
客户端库➜ 删除com.sun.awt.AWTUtilities类
所述com.sun.awt.AWTUtilities类用弃用forRemoval=true在JDK 10（JDK-8187253）。此类在JDK中未使用，已在此版本中删除
客户端库/ 2D➜ 从Oracle JDK中删除Lucida字体
Oracle JDK不再提供任何字体，完全依赖于操作系统上安装的字体。
这意味着来自JDK的应用程序不再提供Bigelow＆Holmes Lucida系列（Lucida Sans，Lucida Bright和Lucida打字机）中的字体。
如果应用程序依赖于JDK中提供的字体，则可能需要更新它们。
如果系统管理员正在运行依赖于JDK中提供的字体而不是系统字体包的Java服务器应用程序，则在安装系统字体包之前，应用程序可能无法运行。
客户端库/ java.awt中➜ 删除appletviewer启动器
该appletviewer工具在JDK 9中已弃用（请参阅JDK-8074165）并在此版本中已删
客户端库/ javax.imageio中➜OracleJDK 的javax.imageio JPEG插件不再支持带alpha的图像
以前，Oracle JDK使用广泛使用的IJG JPEG库的专有扩展来提供可选的色彩空间支持。这用于支持PhotoYCC和具有读取和写入的alpha分量的图像。Oracle JDK 11中已删除此可选支持。除非先前由早期版本的Oracle JDK编码，否则不可能以任何这些格式遇到编码的JPEG图像。但是，如果遇到它们，解码现在将失败并出现异常。使用Alpha通道编写图像也会失败，但会出现异常。最可能出现问题的方案是不知道他们依赖这种支持的应用程序。如果直接调用ImageWriter或使用Image I / O便捷方法，则可能会失败并出现异常。该write()方法现在将返回false,意味着它没有写入图像。
精心编写的应用程序应检查这些方案，这将缓解这种情况。请注意，OpenJDK从未拥有此可选的专有支持。它总是失败并在这些场景中生成异常。
有关不再支持的内容的详细信息，请参阅Java Image I / O JPEG元数据规范中的可选颜色空间支持：https：//docs.oracle.com/javase/10/docs/api/javax/imageio/元数据/文件，文件/ jpeg_metadata.html＃彩见JDK-8204187
核心库➜ 删除sun.misc.Unsafe.defineClass
该sun.misc.Unsafe.defineClass课程已被删除。用户应该使用java.lang.invoke.MethodHandles.Lookup.defineClassJava SE 9中添加的公共替换。有关更多详细信息，请参阅Java文档：
https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A
核心库/ java.lang中➜ 删除Thread.destroy（）和Thread.stop（Throwable）方法
这些方法Thread.destroy()和Thread.stop(Throwable)已被删除。它们已被弃用于多个Java SE版本。该Thread.destroy()方法从未实现，并且该Thread.stop(Throwable)方法自Java SE 8以来一直不起作用。没有代码应该依赖于这两种方法的行为; 但是，任何使用这些方法的代码都会导致编译错误。缓解是从源代码中删除对这些方法的引用。请注意，无参数方法Thread.stop()不受此更改的影响。请参阅JDK-8204243
核心库/ java.nio中➜ 删除sun.nio.ch.disableSystemWideOverlappingFileLockCheck属性
该物业sun.nio.ch.disableSystemWideOverlappingFileLockCheck已被删除。因此，也消除了与旧锁定方法的兼容性。
JDK 6引入了系统属性sun.nio.ch.disableSystemWideOverlappingFileLockCheck来控制文件锁定行为。具体来说，该属性用于启用对JVM范围文件锁定的抑制，并提供与JDK 1.4和JDK 5的兼容性。旧行为仅限于检查仅在通道实例上获得的锁，而不是在JVM范围内获取的锁，这就是实际指定
核心库/ java.util中：I18N➜ 删除sun.locale.formatasdefault属性
sun.locale.formatasdefaultJDK 7中为向后兼容而引入的系统属性已被删除。
芯-SVC / javax.management➜ 删除JVM-MANAGEMENT-MIB.mib
JVM-MANAGEMENT-MIB.mib已删除通过SNMP进行JVM监视和管理的规范。客户可以使用JMX来监视和管理正在运行的JVM，并访问标准的度量和操作集
核心SVC /工具➜ 删除SNMP代理
该jdk.snmp模块已被删除。
因此，com.sun.management.snmp.*使用-D选项或management.properties配置设置时，以下属性为no-op 。
-
com.sun.management.snmp.port
-
com.sun.management.snmp.trap
-
com.sun.management.snmp.interface
-
com.sun.management.snmp.acl
-
com.sun.management.snmp.acl.file
部署➜ 删除Java部署技术
现已删除了在JDK 9中已弃用并标记为在JDK 10中删除的候选者的Java插件和Java WebStart技术。请注意，用于配置部署技术的Java控制面板也已与共享系统JRE（但不是服务器JRE）和JRE自动更新机制一起删除。本白皮书中提供了更多详细信息。
基础设施➜ 从Oracle JDK中删除JMC
JDK捆绑包中不再包含Java Mission Control（JMC）。独立版本的JMC与Oracle JDK 11和OpenJDK 11兼容，可单独下载。
JavaFX的/其他➜ 从Oracle JDK中删除JavaFX
JavaFX模块已从JDK 11发行版中删除。这些模块包含在早期版本的Oracle JDK中，但不包含在OpenJDK版本中。JavaFX模块将作为JDK之外的单独模块集提供。有关更多详细信息，请参见本白皮书：http：//www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
其他 - 库➜ JEP 320卸下Java EE和CORBA模块
从Java SE Platform和JDK中删除Java EE和CORBA模块。这些模块在Java SE 9中已被弃用，声明的意图是在将来的版本中删除它们（JEP 320）。
已从Java SE 11和JDK 11中删除以下模块：
-
java.xml.ws （JAX-WS，以及相关技术SAAJ和Web服务元数据）
-
java.xml.bind （JAXB）
-
java.activation （JAF）
-
java.xml.ws.annotation （通用注释）
-
java.corba （CORBA）
-
java.transaction （JTA）
-
java.se.ee （上面六个模块的聚合器模块）
-
jdk.xml.ws （JAX-WS工具）
-
jdk.xml.bind （JAXB工具）
从jdk.xml.ws模块中删除以下JAX-WS工具：
从jdk.xml.bind模块中删除以下JAXB工具：
从java.corba模块中删除以下CORBA工具：
-
idlj
-
orbd
-
servertool
-
tnamesrv
该rmic编译器更新，删除-idl和-iiop选择。因此，RMI编译器将不再能够生成IDL或IIOP存根和绑定类。
此外，由于删除了Java EE和CORBA模块，以下系统属性不再适用：
-
com.sun.xml.internal.ws.client.ContentNegotiation
-
com.sun.xml.internal.ws.legacyWebMethod
-
javax.xml.bind.context.factory
-
javax.xml.bind.JAXBContext
-
javax.xml.soap.MetaFactory
-
javax.xml.ws.spi.Provider
-
jaxb.fragment
-
jaxb.noNamespaceSchemaLocation
-
jaxb.schemaLocation
-
jaxb.formatted.output
-
jaxb.encoding
-
mail.mime.decodetext.strict
-
mail.mime.encodeeol.strict
-
mail.mime.foldencodedwords
-
mail.mime.foldtext
-
mail.mime.charset
-
saaj.mime.optimization
-
saaj.lazy.contentlength
-
saaj.lazy.contentlength
-
saaj.lazy.mime.optimization
不推荐使用的功能和选项
本节介绍已在本发行版中标识为已弃用的已弃用的API，功能和选项，并且可能会从将来的Java SE和JDK版本中删除。它们应该考虑到这种可能性。此处描述的API是随Oracle JDK提供的API。它包括Java SE 11平台的完整实现和其他Java API，以支持Java应用程序的开发，调试和监视。
有关Java SE 11和JDK 11中不推荐使用的API，功能和选项的其他信息来源包括：
-
不推荐使用的API页面（API规范） - 标识所有已弃用的API，包括Java SE 11中不推荐使用的API。
-
Java SE 11（18.9）（JSR 384）规范 - 文档对Java SE 10和Java SE 11之间的规范的更改，包括已弃用的API的标识和此处未描述的功能。
您应该了解这些文档中的内容以及本发行说明页面中描述的项目。
弃用API的描述可能包括到的废弃警告引用forRemoval=true和forRemoval=false。该forRemoval=true文本表明可能会从下一个主要版本中删除已弃用的API。该forRemoval=false文本表明，不推荐使用已弃用的API从下一个主要版本中删除，但可能会在以后的某个版本中删除。
注意： JEP 277：增强的弃用提供了弃用策略的详细说明。您应该了解本文档中描述的更新策略。
下面的描述还指出了迁移到JDK 11时可能遇到的潜在兼容性问题。有关特定兼容性问题的说明，请参阅“JDK 11迁移指南”。有关在JDK 11中关闭的CSR列表，请参阅已批准用于JDK 11的CSR。
核心库/ java.util.concurrent中➜ 的ThreadPoolExecutor不应该指定的定稿一个依赖
以前版本的ThreadPoolExecutor有一个关闭线程池的finalize方法，但在这个版本中，finalize方法什么都不做。除非子类显式调用finalize方法并依赖执行程序关闭，否则这应该没有可见效果
文档➜ JEP 335弃用犀牛的JavaScript引擎
弃用Nashorn JavaScript脚本引擎和API以及jjs工具，意图在将来的版本中删除它们（JEP 335）。
Nashorn JavaScript Engine实现，API和jjsshell工具已被弃用，可能会在将来的版本中删除。使用来自jdk.nashorn.api.scripting和jdk.nashorn.api.tree包的类和接口的代码将从中获取弃用警告javac。
Nashorn引擎（当由javax.scriptAPI或jrunscript工具使用时）以及jjsshell工具将打印关于弃用的警告消息。要禁用此运行时警告消息，用户可以包含新的Nashorn选项--no-deprecation-warning。这可能对依赖于精确输出的兼容性脚本很有用（例如，以避免警告中断其预期的确切输出）。
热点/编译➜ 弃用-XX + AggressiveOpts
VM选项-XX:+AggressiveOpts在JDK 11中已弃用，将在以后的版本中删除。该选项最初应该能够实现C2编译器的实验性优化，以提高特定基准的性能。随着时间的推移，大多数功能已被删除或集成，使选项的行为定义不明确且容易出错。标志当前具有的唯一影响是设置AutoBoxCacheMax为20000和BiasedLockingStartupDelay500.可以通过从命令行设置相应的标志来实现相同的配置。因此，-XX:+AggressiveOpts将来的版本将不再提供。
热点/运行➜ 对商业功能的过时支持
的-XX:+UnlockCommercialFeatures和-XX:+LogCommercialFeatures命令行参数已过时，以及如果使用的话就会产生一个警告信息。命令行参数，用于控制VM中商业/许可功能的使用和日志记录。由于不再有这样的功能，命令行参数不再有用。
同样，VM.unlock_commercial_features和VM.check_commercial_featuresjcmd命令也会生成警告消息，但没有其他影响。
安全库/ org.ietf.jgss中➜ 弃用基于流的GSSContext方法
GSSContext此版本中已弃用基于流的方法，因为GSS-API适用于不透明的令牌，并且尚未定义有线协议。这包括重载形式的initSecContext，acceptSecContext，wrap，unwrap，getMIC，和verifyMIC具有一个方法InputStream的参数。这些方法已在RFC 8353中删除。
工具➜ JEP 336弃用Pack200工具和API
在（JEP 336）中弃用pack200和unpack200工具以及Pack200 API 。java.util.jar
该pack200API和与之相关的工具，pack200并且unpack200，已被弃用，并将在未来的版本中删除。
这些工具仍包含在JDK 11中，但不再更新以支持最新的类文件格式。具有未知属性的类文件将在不压缩的情况下传递。
其他说明
以下注释描述了有关此版本的其他更改和信息。在某些情况下，以下说明提供了有关问题或更改的其他详细信息的链接。
客户端库/ java.awt中➜ GTK3现在是在Linux / Unix默认
较新版本的Linux，Solaris和其他Unix风格桌面环境使用GTK3，同时仍支持GTK2。
以前，JDK默认加载旧的GTK2库。但是，在此版本中，它默认为加载GTK3库。通常使用Swing GTK外观触发加载。
如果由于任何原因导致应用程序出现问题，则可以使用系统属性恢复旧行为： -Djdk.gtk.version=2.2
核心库/ java.io：系列化➜ 更好的堆栈行走
在反序列化的对象创建阶段添加了新的访问检查。这不应影响反序列化的普通用法。但是，使用JDK内部API的反射框架可能会受到影响。如有必要，可以通过将系统属性jdk.disableSerialConstructorChecks设置为值“true” 来禁用新检查。必须通过将参数添加-Djdk.disableSerialConstructorChecks=true到Java命令行来完成此操作。
核心库/ java.lang中➜ 方法ClassgetAnnotation抛出TypeNotPresentException当记类不存在
当java.lang.Class::getAnnotation调用以检索注释，并且注释具有引用缺少的类的数组值时，尝试读取该值会导致a java.lang.TypeNotPresentException。
在以前的版本中，调用Class::getAnnotation错误导致a java.lang.ArrayStoreException。应该更新任何明确处理该异常的程序以进行处理java.lang.TypeNotPresentException。
核心库/ java.lang中➜ 有效地只读一些系统属性
的值java.home，user.home，user.dir，和user.name属性在启动缓存。使用System::setProperty启动后所做的更改不会更改java.base模块中API的行为 。
核心库/ java.lang中➜java.lang.ref.Reference 不支持克隆
java.lang.ref.Reference::clone方法总是抛出CloneNotSupportedException。Reference对象不能被有意义地克隆。要创建新的Reference对象，请调用构造函数以创建Reference具有相同引用和引用队列的对象。
核心库/ java.lang.invoke➜ filterArguments运行在错误的顺序多个过滤器
java.lang.invoke.MethodHandles.filterArguments澄清了该方法的规范，以更清楚地说明过滤器参数是按从左到右的顺序调用的。此方法的实现也已修复，以确保它符合规范。在修复之前，实现错误地从右到左调用过滤器。对于大多数用法，预计行为的变化是不可观察的。只有在少数情况下，两个或多个过滤器具有影响其结果的副作用，才能观察到行为的变化。
核心库/ java.lang.module➜ 更改为在类路径上编译或运行代码时解决的默认模块集的策略
在类路径上编译代码或运行代码时，默认的根模块集在JDK 11中已更改为导出API的所有可观察系统模块。唯一可观察到的更改是java.se默认情况下不再解析模块。
核心库/ java.net➜ 当URL数组包含Null的URLClassLoader没有指定行为
如果URL数组包含null元素，则指定URLClassLoader的构造函数抛出NullPointerException。
核心库/ java.nio中➜ 先前在SelectionKey Ready Set中保留的准备信息
该java.nio.channels.SelectorAPI指定如何精确选择操作添加选择键来选择的选择键集或组已经更新选择键的准备信息。SelectorJDK中的实现在历史上没有正确地实现后者，这意味着在选择了通道并且其密钥已经在选择密钥集中的情况下，覆盖了就绪信息并且未保留先前的就绪信息。此问题已在JDK 11中得到修复。此行为更改可能会使执行另一个选择操作之前调用select（或selectNow）并且不处理添加到selected-key集的键的代码感到惊讶。
核心库/ java.nio中➜ 当选择操作正在进行时，可以调用SelectableChannel.register
java.nio.channels.Selector历史上指定其键集（包含表示用选择器注册的通道的键的集合）不是线程安全的。指定了选择操作以在此密钥集上进行同步。此外，register由java.nio.channels.SelectableChannel（SocketChannel，ServerSocketChannel...）定义的方法也被指定为在选择器的键集上同步，因此如果与另一个注册或选择操作同时调用则阻塞。
Java SE 11中的规范已更改，因此选择器的密钥集被指定为并发线程可以安全使用。不再指定选择操作以在密钥集上进行同步。这允许线程在选择操作正在进行时注册通道; 新注册在下一个选择操作中生效。SelectionKey interestOps(int)也被重新指定，以便随时可以调用它。如果在选择操作正在进行时调用，则它对该操作没有影响; 下一个选择操作将看到对密钥兴趣集的更改。
在Selector所选的密钥集上同步的代码不受此更改的影响，因为继续指定选择操作以在所选密钥集上进行同步。
该SelectorAPI是可插拔的。SelectorProvider需要更新存在于JDK之外的实现，以使其Selector实现与更新的规范保持一致
核心库/ java.nio中➜ DatagramChannel.send抛出AlreadyConnectedException而不是抛出：IllegalArgumentException
之前JDK 11，调用DatagramChannel.send(ByteBuffer,SocketAddress)一个DatagramChannel连接以从指定给该方法的地址不同的地址造成未指定IllegalArgumentException被抛出。在Java SE 11中，已明确规范以指定java.nio.channels.AlreadyConnectedException此情况，并且已更改实现以引发正确的异常。
核心库/ java.nio中➜ 单独阻止和非阻塞代码路径
的实施方式中SocketChannel，ServerSocketChannel，DatagramChannel，Pipe.SourceChannel和Pipe.SinkChannel已重构在JDK 11向代码路径用于阻挡和非阻挡I / O分离。这可以提高性能，并且还可以在异步关闭通道或执行I / O操作的线程中断的情况下提高可靠性。重构导致以下行为更改：
1.关闭SocketChannel已使用a注册的已连接Selector将立即延迟关闭基础连接，直到从已注册的所有选择器中清除已关闭的通道。类似地，关闭ServerSocketChannel已注册的Selector将立即延迟关闭底层侦听器套接字，直到从其注册的所有选择器中刷新它。在以前的版本中，平台的行为有所不同。使用netstat监视网络连接等工具的开发人员应该了解这一变化，特别是对于未及时执行选择操作的库或应用程序来清除选择器中的封闭通道。
2.在配置为非阻塞且可设置中断状态的可选通道上调用I / O操作不再关闭通道。
3.调用configureBlocking(false)可选择的通道现在将阻塞，直到完成未完成的阻塞I / O操作。规范总是允许这样做，但JDK中的实现在历史上一直没有等到阻塞正在进行的I / O操作完成。
核心库/ java.util中：I18N➜ 日本新时代的实施
日本的日历，包括java.time.chrono和java.util包装都支持即将到来的日本新时代，这个时代将于2019年5月1日生效。目前，这个时代的名称尚不清楚，占位符名称（“元号”为日语，“ NewEra“用于其他语言”是为其显示名称提供的。在将来的更新中，占位符名称将替换为合法的时代名称，因此应用程序不应依赖于这些占位符名称。使用整数值来代替新时代。例如：
java.time.chrono.JapaneseEra.of(3).getDisplayName(TextStyle.FULL, Locale.US)
要么new java.util.Calendar.Builder()
.setCalendarType("japanese")
.setFields(Calendar.ERA, 5,
Calendar.YEAR, 1,
Calendar.MONTH, Calendar.MAY,
Calendar.DAY_OF_MONTH, 1)
.build()
.getDisplayName(Calendar.ERA, Calendar.LONG, Locale.US)
将输出“NewEra”
文档➜ 启用JDK 11安装程序的控制面板中的Java Access Bridge复选框选项不可用
Windows控制面板中的Java Access Bridge复选框在JDK11中不可用。此注册是公共JRE安装的一部分。
但是，仍可以通过以下步骤启用和禁用Java Access Bridge：
1.复制%JAVAHOME%\bin\windowsaccessbridge-64.dll到%WINDOWSHOME%\SYSTEM32。此步骤后可能需要重新启动。
2.运行%JAVAHOME%\bin\jabswitch /enable和%JAVAHOME%\bin\jabswitch /disable。
注意：%WINDOWSHOME%安装Microsoft Windows的目录（例如C:\WINDOWS）%JAVAHOME%是安装JDK的目录（例如C:\Program Files\Java\jdk-11）
热点/ GC➜提供 用于并发GC的STW阶段的新PerfCounters
在并发阶段添加了一个新的GC性能计数器用于暂停。该计数器将jstat在CGC（并行GC）标题下列出。此信息仅适用于具有并发阶段且具有GC特定的GC：
-
G1包括备注和清理暂停
-
CMS包括初始标记和备注暂停
对于CMS，这些暂停先前包含在jstatFGC（完整GC）标题下列出的时间内。
该信息也可通过jcmd使用获得PerfCounter.print。
热点/ GC➜G1 默认启用自适应并行参考处理
默认情况下，G1现在确定java.lang.ref.Reference在垃圾回收期间用于处理的最佳线程数。默认情况下-XX:ParallelRefProcEnabled，标志现在true（已启用）。
在具有多个可用于垃圾回收的线程的计算机上，此更改显着改善了垃圾收集暂停的此阶段。
如果您遇到垃圾收集暂停的增加，则可以通过-XX:-ParallelRefProcEnabled在命令行上指定来恢复原始行为。java.lang.ref.Reference可以使用实验选项-XX:ReferencesPerThread（默认值：1000）调整处理的适应性
热点/ GC➜ 如果选择了不可用的GC，则立即失败
以前，如果用户在命令行上选择了不可用的垃圾收集器（例如，“最小”JVM构建中不存在G1垃圾收集器），则JVM将发出警告并继续执行，通过静默选择一个可用的垃圾收集器。此行为已更改。JVM现在将打印错误消息，并在用户选择不可用的垃圾收集器时立即终止
热点/ GC➜ 垃圾收集器默认情况下自适应地缩放线程数
垃圾收集器在垃圾收集中使用的线程数停止世界暂停根据Java堆的最大大小确定要使用的线程数。默认情况下，标志-XX：UseDynamicNumberOfGCThreads现在为true（已启用）。
这样可以缩短启动时间并减少资源使用，尤其是对于使用小型Java堆运行的Java应用程序。
如果您在使用少量Java堆的应用程序上遇到性能降低，则可以通过在命令行上指定-XX： - UseDynamicNumberOfGCThreads来禁用此新行为。
热点/ GC➜ 使用较旧的NUMA库（-XX + UseNuma）提高稳定性
JDK 8 Update 152中包含的修复程序引入了一个回归，当在具有早于2.0.9的libnuma版本的Linux系统上使用UseNUMA标志时，该回归可能导致HotSpot JVM在启动期间崩溃。此问题已得到解决。
热点/ JVMTI➜ 如果禁用JVMTI_EVENT_FRAME_POP，则NotifyFramePop请求不会被清除
在之前的版本中，NotifyFramePop请求仅在JVMTI_EVENT_FRAME_POP启用时清除。现在，无论是否JVMTI_EVENT_FRAME_POP启用相应的帧，它总是被清除。
热点/运行➜ 扩展类数据共享（CDS）以支持模块路径
在JDK 11中，类数据共享（CDS）已得到改进，以支持模块路径中的归档类。
要使用--module-pathVM选项创建CDS存档，命令行语法如下：$ java -Xshare:dump -XX:SharedClassListFile=<class list file> \
-XX:SharedArchiveFile=<shared archive file> \
--module-path=<path to modular jar> -m <module name>
要使用--module-pathVM选项运行CDS存档，命令行语法如下：$ java -Xshare:on -XX:SharedArchiveFile=<shared archive file> \
--module-path=<path to modular jar> -m <module name>
下表描述了与模块路径相关的VM选项如何与该-Xshare选项一起使用。
|
|
-Xshare：转储 |
-Xshare：{上，自动} |
|
--module-path1 <mp> |
允许 |
允许2 |
|
--module |
允许 |
允许 |
|
--add-module |
允许 |
允许 |
|
--upgrade-module-path3 |
不允许（如果指定则退出） |
允许（禁用CDS） |
|
--patch-module4 |
不允许（如果指定则退出） |
允许（禁用CDS） |
|
--limit-modules五 |
不允许（如果指定则退出） |
允许（禁用CDS） |
1虽然有两种方法可以指定模块--module-path，即模块化模块.jar或分解模块，但只.jar支持模块化文件。
2转储时间与运行时间之间可以指定不同的<mp>。如果在转储时K加载了一个归档类mp1.jar，但<mp>中的更改导致它mp2.jar在运行时从不同的地方可用，则在运行时K将忽略归档版本; K将动态加载。
3目前，只有两个系统模块可升级（java.compiler和jdk.internal.vm.compiler）。这些在生产软件中很少升级。
4正如JEP 261中所述，--patch-module强烈建议不要进行生产使用。
图5--limit-modules用于测试目的。它很少用于生产软件。
如果中的任何一个--upgrade-module-path，--patch-module或者--limit-modules是在转储时间指定，将要打印的下面的错误和JVM将退出。例如，如果--limit-modules在转储时指定了该选项，则用户将看到以下错误：Error occurred during initialization of VM
Cannot use the following option when dumping the shared archive: --limit-modules
如果中的任一项--upgrade-module-path，--patch-module或--limit-modules在运行时指定，以下警告消息将被打印指示CDS被禁用。例如，如果--limit-modules在运行时指定了该选项，则用户将看到以下警告：Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified.
还有一些值得注意的值得注意的事情：
1.任何有效的组合-cp和--module-path支持。
2.模块路径中的非空目录会导致致命错误。用户将看到以下错误消息：
错误：非空目录<directory>提示：启用-Xlog：class + path = info以诊断故障VM初始化期间发生错误路径中不能包含非空目录
3.与类路径不同，转储时的模块路径必须等于或是运行时模块路径的前缀。
4.如果在存档生成后更新模块路径中的现有JAR，则存档无效。
5.从模块路径中删除JAR不会使共享存档失效。已删除的JAR中的归档类不会在运行时使用。
