Java SE Development Kit是Java 开发工具包,拥有出色的软件开发工具!编写 Java 小应用程序和应用程序需要类似于 JDK 的开发工具。JDK 包括 Java 运行时环境、Java 编译器和 Java API。无论是编程新手还是有经验的程序员,都很容易入门。这个功能强大的Java编程语言套件及其新的更新为其套件增加了额外的功能和功能,可以帮助开发Java开发人员和程序员。此外,这个大型套件可以完全测试和运行您的扩展软件。Java SE Development Kit将提供Java编程所需的大量软件和工具。能够测试和运行由Java编程语言开发的软件。包含注释处理工具。idjlDL编译器到Java。非常实用程序,方便的进行软件开发!
从JDK 10及更高版本开始,版本字符串的格式反映了Java SE平台的基于时间的发布模型$FEATURE.$INTERIM.$UPDATE.$PATCH。
$FEATURE是每个功能版本增加的版本号。功能版本包含新功能以及Java SE平台规范指定的现有功能的更改。版本号每六个月递增一次。例如,2018年3月发行版的版本号为10,2018年9月发行版的版本号为11,依此类推。
$INTERIM是每个临时版本增加的版本号,其中包含错误修复和增强功能。临时版本不包含不兼容的更改,功能删除,也不包含对标准API的任何更改。由于六个月的发布模型不包含临时版本,因此临时版本的版本号始终为零(0)。但是,此版本号保留用于将来的临时版本(如果有)。
$UPDATE是更新版本增加的版本号,其中包括针对安全问题,回归和新功能中的错误的修复程序。版本号在$FEATURE发布后一个月递增,之后每三个月递增一次。例如,完整的版本号为10月更新版本是13 .0.1,完整的版本号为1月更新版本是13 .0.2,等等。
版本字符串没有尾随零元素。例如,如果值$FEATURE是13,的值$INTERIM是0,的值$UPDATE是1,和的值$PATCH是0,则完整的版本号是13 .0.1。
注意:Windows 7和Windows 10有一个开始菜单; 但是,该菜单在Windows 8和Windows 8.1中不可用。Windows 8和Windows 8.1中的JDK和Java信息可在以下Start目录中找到:%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs。
如果安装目录不是系统区域设置的代码页的一部分,则可能会发生1722错误。要防止这种情况发生,请确保用户和系统区域设置完全相同,并且安装路径仅包含属于系统区域设置代码页的字符。可以在“ 区域选项”或“ 区域设置”控制面板中设置用户和系统 区域设置。
Java语言中添加了文本块,可以在需要时为开发人员提供对格式的控制。这是一种预览语言功能。请参阅JEP 355文本块(预览)和JEP 12:预览语言和VM功能。
的switch表达,预览的语言特性,一直延续到被用作任何声明或表达式,从而使这两种形式可以使用传统的标签(与告吹)或新标签(没有落空)。它与另一个新语句一起使用,用于从switch表达式中生成值。请参阅JEP 354:切换表达式(预览)和JEP 12:预览语言和VM功能。
java.net.Socket和 java.net.ServerSocketAPI 使用的实现被 更简单,更现代的实现取代,易于维护和调试。请参阅JEP 353:重新实现旧版套接字API。
ZGC已得到增强,可将未使用的堆内存返回给操作系统,从而增强了应用程序的内存占用。请参阅JEP 351 ZGC Uncommit Unused Memory。
提供Zip文件系统提供程序的实现。
JDK 13中的新功能 - 新功能和增强功能
本节介绍Java SE 13和JDK 13中的一些增强功能。在某些情况下,说明提供了有关问题或更改的其他详细信息的链接。此处描述的API是随Oracle JDK提供的API。它包括Java SE 13平台的完整实现和其他Java API,以支持Java应用程序的开发,调试和监视。关于Java SE 13和JDK 13中重要增强功能和新功能的另一个信息来源是Java SE 13(JSR 388)平台规范,记录了Java SE 12和Java SE 13之间对规范的更改。本文档包括对规范进行更改的那些新功能和增强功能的描述。这些描述还标识了迁移到JDK 13时可能遇到的潜在兼容性问题。
核心库/ java.nio中
➜ 添加了FileSystems.newFileSystem(Path,Map <String,?>)方法
添加了三种新方法java.nio.file.FileSystems,以便更轻松地使用将文件内容视为文件系统的文件系统提供程序。
newFileSystem(Path)
newFileSystem(Path, Map<String, ?>)
newFileSystem(Path, Map<String, ?>, ClassLoader)
添加为newFileSystem(Path, Map<String, ?>)已使用现有2-arg newFileSystem(Path, ClassLoader)并指定类加载器的代码创建源(但不是二进制)兼容性问题。null.例如,由于引用newFileSystem不明确,因此无法编译以下内容:
FileSystem fs = FileSystems.newFileSystem(path, null);
为了避免模糊引用,需要修改此代码以将第二个参数强制转换为java.lang.ClassLoader。
见JDK-8218875
核心库/ java.nio中
➜ 新的java.nio.ByteBuffer批量获取/放置方法转移字节而不考虑缓冲区位置
java.nio.ByteBufferjava.nio现在,其他缓冲区类型定义绝对批量get和put传输连续字节序列的方法,而不考虑或影响缓冲区位置。
见JDK-5029431
核心库/ java.time
➜ 新日本时代名称Reiwa
此更新中添加了代表新Reiwa时代的实例。与其他时代不同,这个时代没有公共领域。它可以通过调用JapaneseEra.of(3)或获得JapaneseEra.valueOf("Reiwa")。JDK 13及更高版本将有一个新的公共领域来代表这个时代。
NewEra从2019年5月1日开始的日本时代的占位符名称“ ”已被新的官方名称取代。依赖占位符名称(请参阅JDK-8202088)获取新时代单例(JapaneseEra.valueOf("NewEra"))的应用程序将不再起作用。
请参阅JDK-8205432
核心库/ java.util中:I18N
➜ 支持Unicode 12.1
此版本将Unicode支持升级到12.1,其中包括以下内容:
java.lang.Character支持12.1级的Unicode字符数据库,其中12.0从11.0开始增加554个字符,总共137,928个字符。这些新增内容包括4个新脚本,总共150个脚本,以及61个新的表情符号字符。U+32FF SQUARE ERA NAME REIWA从12.0开始,12.1只添加一个字符。
java.text.Bidi和java.text.Normalizer类分别支持12.0级的Unicode标准附件,#9和#15。
java.util.regex package支持基于12.0级Unicode标准附件#29的扩展字形集群
见JDK-8221431
热点/ GC
➜ JEP 351 ZGC取消提交未使用的存储器
ZGC已得到增强,可将未使用的堆内存返回给操作系统。这对于需要考虑内存占用的应用程序和环境非常有用。
默认情况下启用此功能,但可以使用显式禁用-XX:-ZUncommit。此外,内存不会被取消提交,因此堆大小会缩小到最小堆大小(-Xms)以下。这意味着如果将最小堆大小(-Xms)配置为等于最大堆大小(-Xmx),则将隐式禁用此功能。
可以使用-XX:ZUncommitDelay=<seconds>(默认为300秒)配置非提交延迟。此延迟指定在有资格取消提交之前内存应该未使用多长时间。
有关详细信息,请参阅(JEP 351)。
见JDK-8220347
热点/ GC
➜ 添加了-XXSoftMaxHeapSize标志
-XX:SoftMaxHeapSize=<bytes>添加了可管理的命令行标志。目前,它仅在启用Z垃圾收集器时具有效果(-XX:+UseZGC)。
设置后,GC将努力不使堆超出指定的大小,除非GC决定必须这样做以避免OutOfMemoryError。不允许将软最大堆大小设置为大于最大堆大小(-Xmx)的值。如果未在命令行上设置,则默认值等于最大堆大小。
存在manageable,它的价值可以在运行时调整。例如,可以使用jcmd VM.set_flag SoftMaxHeapSize <bytes>或通过HotSpot MXBean 调整其值。
设置此标志在许多情况下都很有用,例如:
在需要考虑资源使用的环境中,您可能希望保持堆占用空间不足,同时还要保留处理堆空间需求临时增加的功能。
当使用并发GC(例如ZGC)时,您可能希望安全地使用它并增加您不会因为分配率无法预料的增加而进入分配停顿的置信度。设置软最大堆大小会鼓励GC维持较小的堆,这意味着GC将比其他方式更积极地收集垃圾,使其更加适应应用程序分配率的突然增加。
见JDK-8222145
热点/ GC
➜ ZGC最大堆大小增加到16TB
ZGC支持的最大堆大小从4TB增加到16TB。
见JDK-8221786
热点/运行
➜ JEP 350动态CDS归档
JEP 350扩展了应用程序类 - 数据共享(AppCDS),允许在Java应用程序退出时动态存档类。它还通过消除用户进行试运行以创建每个应用程序的类列表的需要来提高AppCDS的可用性。-Xshare:dump选项启用的现有静态归档使用类列表继续按原样工作。
动态生成的存档是在与正在运行的JDK映像一起打包的默认系统存档之上创建的。为每个应用程序生成单独的顶层归档文件。用户可以指定动态存档名称的文件名作为-XX:ArchiveClassesAtExit选项的参数。例如,以下命令创建hello.jsa:
% bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello
要使用此动态存档运行相同的应用程序:
% bin/java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello
用户还可以在-XX:SharedArchiveFile选项中指定基本和动态存档,例如:
-XX:SharedArchiveFile=<base archive>:<dynamic archive>
CSR JDK-8221706有关于命令行选项的更多详细信息。
见JDK-8207812
安全库/ java.security
➜CRL的可 配置读取超时
该com.sun.security.crl.readtimeout系统属性设置为CRL检索的最大读取超时,单位为秒。如果尚未设置该属性,或者其值为负,则将其设置为默认值15秒。值0表示无限超时。
见JDK-8191808
安全库/ java.security
➜ 新的keytool -showinfo -tls用于显示TLS配置信息的命令
keytool -showinfo -tls添加了一个显示TLS配置信息的新命令。
见JDK-8219861
安全库/ javax.crypto中
➜ 支持MS Cryptography Next Generation(CNG)
SunMSCAPI提供程序现在支持以下一代加密(CNG)格式读取私钥。这意味着CNG格式的RSA和EC密钥可从Windows密钥库加载,例如“Windows-MY”。与EC(签名算法SHA1withECDSA,SHA256withECDSA等等)也支持。
见JDK-8026953
安全库/ javax.crypto中:PKCS11
➜ SunPKCS11提供升级与PKCS#11 V2.40支持
SunPKCS11提供程序已更新,支持PKCS#11 v2.40。此版本增加了对更多算法的支持,例如AES / GCM / NoPadding密码,使用SHA-2系列消息摘要的DSA签名,以及当底层PKCS11库支持相应PKCS11机制时的RSASSA-PSS签名。
见JDK-8080462
安全库/ javax.net.ssl中
➜ 支持TLS中的X25519和X448
命名的椭圆曲线组x25519和x448现在都可以在TLS版本1.0到1.3 JSSE密钥协商,与x25519为最优选的默认启用的命名组。现在默认的有序列表是:
x25519, secp256r1, secp384r1, secp521r1, x448,
sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1,
secp256k1,
ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192
可以使用系统属性覆盖默认列表jdk.tls.namedGroups。
见JDK-8171279
安全库/ javax.net.ssl中
➜JSSE中 没有服务器端状态的会话恢复
该功能允许JSSE的服务器端运行无状态。如针对TLS 1.2及更低版本的RFC 5077 1和针对TLS 1.3的RFC 8446 2所述,TLS服务器以加密会话票证的形式将内部会话信息发送到支持无状态的客户端。在TLS握手期间,该会话票证将呈现给服务器以恢复会话。这应该可以提高大型工作负载下TLS服务器的性能和内存使用率,因为很少使用会话缓存。缓存的会话信息较少,某些会话信息可能不可用。默认情况下不启用此功能,可以通过设置两个属性来打开此功能。
请注意,无效的无状态TLS会话可以在当前实现中恢复。在将来的版本和更新中,行为不保证是相同的(请参阅bugid JDK-8229148)。
请注意,在当前实现中,SSLSession.getID()对于TLS 1.3和无状态TLS 1.2连接的恢复,返回值不是持久的。如果应用程序依赖会话标识符值,这可能是一个问题。这可能会改变为未来版本的一致性(请参阅bugid JDK-8229149)。
添加了两个新的系统属性以支持此功能:jdk.tls.client.enableSessionTicketExtension在客户端使用以在TLS 1.2的ClientHello消息上切换会话票证扩展。属性值:“ true”发送扩展名,“ false”不发送(默认)。
jdk.tls.server.enableSessionTicketExtension如果客户端支持,则使服务器可以使用无状态会话票证。不支持无状态会话票证的客户端将使用缓存。属性值:“ true”启用无状态,“ false”不启用(默认)。
见JDK-8211018
安全库/ javax.security
➜ 允许限制SASL机制
添加了一个名为的安全属性jdk.sasl.disabledMechanisms,可用于禁用SASL机制。如果在mechanisms参数of Sasl.createSaslClient或mechanism参数中指定了任何禁用的机制,则将忽略它Sasl.createSaslServer。此安全属性的默认值为空,这意味着没有任何机制被禁用。
见JDK-8200400
安全库/的javax.xml.crypto
➜PancicalXML 1.1 URI的新字符串常量
新的String常量已命名INCLUSIVE_11并INCLUSIVE_11_WITH_COMMENTS已添加到javax.xml.crypto.dsig.CanonicalizationMethodAPI中。它们代表Canonical XML 1.1和Canonical XML 1.1的URI以及XML签名的注释算法。
见JDK-8224767
安全库/的javax.xml.crypto
➜ [xmldsig]添加了KeyValueEC_TYPE
现在支持W3C XML签名语法和处理建议中ECKeyValue描述的类型。接口添加了一个新常量。请注意,目前仅支持域参数类型,并且不支持显式曲线参数类型。EC_TYPEjavax.xml.crypto.dsig.keyinfo.KeyValueNamedCurveECParameters
见JDK-8223053
安全库/ org.ietf.jgss中
➜ 在Windows上添加了默认本机GSS-API库
Windows平台上的JDK中添加了本机GSS-API库。该库仅限客户端,并使用默认凭据。sun.security.jgss.native系统属性设置为“true” 时将加载它。用户仍然可以通过将系统属性sun.security.jgss.lib设置为其路径来加载第三方本机GSS-API库。
见JDK-6722928
安全库/ org.ietf.jgss中:KRB5
➜ 支持Kerberos跨领域引用(RFC 6806)
Kerberos客户端已得到增强,支持主体名称规范化和跨领域引用,如RFC 6806协议扩展所定义。
作为此新功能的结果,Kerberos客户端可以利用更多动态环境配置,并且不一定需要(事先)知道如何到达目标主体(用户或服务)的领域。
默认情况下启用支持,5是允许的最大引用跳数。要将其关闭,请将sun.security.krb5.disableReferralssecurity或system属性设置为false。要配置自定义最大引用跃点数,请将sun.security.krb5.maxReferralssecurity或system属性设置为任何正值。
请参阅JDK-8223172中的更多信息。
见JDK-8215032
工具/ javac的
➜ JEP 354个开关表达式(预览)
扩展,switch因此它可以用作语句或表达式,这样两个表单都可以使用传统case ... :标签(带有直通)或新case ... ->标签(没有通过),还有一个新的语句用于从a产生值switch表达。这些变化将简化日常编码和使用的制备方法的模式匹配在switch。这是JDK 13中的预览语言功能。
见JDK-8222184
工具/ javac的
➜ JEP 355个的文本块(预览版)
将文本块添加到Java语言。文本块是一个多行字符串文字,它避免了对大多数转义序列的需要,以可预测的方式自动格式化字符串,并在需要时让开发人员控制格式。这是JDK 13中的预览语言功能。
JDK-8223930(非公开)
XML / JAXP
➜ 使用命名空间支持创建DOM和SAX工厂的新方法
默认情况下,添加了新的方法来实例化DOM和SAX工厂,并支持Namespace。这些方法以现有的对应方式为前缀,其中“NS”代表NamespaceAware。以下是新方法的列表:
newDefaultNSInstance()
newNSInstance()
newNSInstance(String factoryClassName, ClassLoader classLoader)
使用这些新方法,默认情况下,通过工厂创建的解析器将是NamespaceAware。例如,以下声明:
DocumentBuilder db = DocumentBuilderFactory.newDefaultNSInstance().newDocumentBuilder();
相当于:
DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance();
dbf.setNamespaceAware(true);
DocumentBuilder db = dbf.newDocumentBuilder();
见JDK-8219692
删除了功能和选项
本节介绍在Java SE 13和JDK 13中删除的API,功能和选项。此处描述的API是随Oracle JDK提供的API。它包括Java SE 13平台的完整实现和其他Java API,以支持Java应用程序的开发,调试和监视。关于Java SE 13和JDK 13中重要增强功能和新功能的另一个信息来源是Java SE 13(JSR 388)平台规范,该规范记录了Java SE 12和Java SE 13之间对规范的更改。本文档包括标识删除的API和此处未描述的功能。下面的描述还可能标识迁移到JDK 13时可能遇到的潜在兼容性问题CSRs已获得JDK 13批准,用于JDK 13中关闭的CSR列表。
客户端库
➜ 删除awt.toolkit系统属性
从历史上看(直到JDK 1.8),java.awt.Toolkit该类的文档引用了“awt.toolkit”系统属性,该属性被设置为平台实现子类的名称。JDK 9中删除了此属性的文档,因为(1)它是一个内部细节,不是支持的接口,(2)模块系统的封装意味着无法直接操作类。但是,系统属性直到现在才被删除。如有必要,以前读取此属性的应用程序仍可通过实例化AWT Toolkit并通过该实例查询类名来获取它。
请参阅JDK-8212700
核心库/ java.lang中
➜ 删除运行时跟踪方法
过时的方法traceInstructions(boolean),并traceMethodCalls(boolean)已经从删除java.lang.Runtime类。这些方法对许多版本都不起作用,它们的预期功能由Java虚拟机工具接口(JVMTI)提供。
见JDK-8205131
核心库/ java.net
➜ 不再支持Pre-JDK 1.4 SocketImpl实现
java.net.SocketImpl此版本已删除对为Java SE 1.3及更早版本编译的自定义实现的支持。此更改对SocketImpl为Java SE 1.4(2002年发布)或更新版本编译的实现没有影响。
见JDK-8216978
热点/运行
➜ 删除VM选项-XX + AggressiveOpts
-XX:+AggressiveOpts在JDK 11中不推荐使用VM选项,并且在JDK 12中删除了对它的支持(除了生成警告之外,它的使用被忽略)。使用此标志现在将导致VM初始化错误。
见JDK-8216188
安全库
➜ 重复的RSA服务不再受SunJSSE提供支持
为支持RSA KeyFactory,RSA KeyPairGenerator,MD2withRSA,MD5withRSA,和SHA1withRSA Signature已经从SunJSSE提供商删除。
自JDK 5以来,SunRsaSign引入了提供程序以支持这些与RSA相关的算法。SunJSSE提供商支持这些的唯一原因是为了与JDK 5之前的应用程序向后兼容。删除应仅影响从SunJSSE提供程序明确请求这些RSA服务的应用程序。应用程序应删除硬编码的“SunJSSE”提供程序名称。
见JDK-8220016
安全库/ java.security
➜ 删除T-Systems Deutsche Telekom Root CA 2证书
T-Systems Deutsche Telekom Root CA 2证书已过期,已从cacerts密钥库中删除:
别名“deutschetelekomrootca2 [jdk]”
专有名称:CN = Deutsche Telekom Root CA 2,OU = T-TeleSec信任中心,O = Deutsche Telekom AG,C = DE
见JDK-8222137
安全库/ java.security
➜ 删除两个DocuSign根CA证书
两个DocuSign根CA证书已过期,已从cacerts密钥库中删除:
别名“certplusclass2primaryca [jdk]”
专有名称:CN = Class 2 Primary CA,O = Certplus,C = FR
别名“certplusclass3pprimaryca [jdk]”
专有名称:CN = Class 3P Primary CA,O = Certplus,C = FR
见JDK-8223499
安全库/ java.security
➜ 删除两个Comodo根CA证书
两个Comodo根CA证书已过期并已从cacerts密钥库中删除:
别名“utnuserfirstclientauthemailca [jdk]”
专有名称:CN = UTN-USERFirst-Client Authentication and Email,OU = http://www.usertrust.com,O = USERTRUST Network,L =盐湖城,ST = UT,C = US
别名“utnuserfirsthardwareca [jdk]”
专有名称:CN = UTN-USERFirst-Hardware,OU = http://www.usertrust.com,O = USERTRUST网络,L =盐湖城,ST = UT,C = US
见JDK-8222136
安全库/ javax.net.ssl中
➜ 删除仅用于与旧版JSSE 1.0应用程序兼容的内部com.sun.net.ssl包
内部包com.sun.net.ssl已从JDK中删除。在Java SE 1.4之前,当JSSE作为独立产品发布时,com.sun.net.sslAPI受支持,但自Java SE 1.4起,该软件包已弃用,仅供内部使用。自Java SE 1.4以来HostNameVerifier,标准替换API(如,KeyManager和)TrustManager已在javax.net.ssl包中提供。虽然应用程序应该已转换为标准API,但本说明是最终警告,已删除这些非标准API。
见JDK-8215430
安全库/ javax.net.ssl中
➜ 从SunJSSE提供商中删除实验性FIPS 140兼容模式
已从SunJSSE提供商中删除了实验性FIPS 140兼容模式。
旧版应用程序可能使用以下方法之一的实验模式:
1.更新java.security文件并为SunJSSE提供程序指定加密提供程序(例如,security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS)
2.使用JDK内部类并使用指定的加密提供程序创建提供程序(例如,new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);)。
由于SunJSSE提供程序使用JDK默认加密提供程序,因此应用程序可以配置security.provider安全属性以使用符合FIPS 140的加密提供程序。
见JDK-8217835
工具/ javadoc的(工具)
➜ 从javadoc工具中删除旧功能
已从javadoc工具中删除以下四个功能:
支持使用HTML 4生成API文档:在JDK 9中添加了对HTML 5的支持,并且自JDK 11以来一直是默认的。要生成完全符合HTML 5规范的API文档,开发人员应确保使用HTML标记在他们的文档注释中也符合HTML 5规范。
支持“旧”javadoc API:这包括模块中的API(com.sun.javadoc),旧标准doclet(com.sun.tools.doclets.standard)和旧入口点(com.sun.tools.javadoc.Start)jdk.javadoc。JDK 9中引入了新的API和新的标准doclet,利用了其他现代建模API,如javax.lang.model。所述的Javadoc工具可以使用以编程调用javax.tools.DocumentationToolAPI,或(对于简单的使用)java.util.spi.ToolProvider。仅使用javadoc工具生成标准API文档的用户不受影响。
支持使用HTML框架生成文档:它已被JDK 9中添加的“搜索”功能以及页面内改进的索引文件和链接所取代。
对--no-module-directories选项的支持:此选项通过JDK 9和10中的javadoc工具为生成的文档所使用的组织提供了有限的支持,其中不同模块的文件未分组到单独的目录中。
见JDK-8215608