JDK 16 Early-Access Release Notes

JEP 380: Unix-Domain Socket Channels has been integrated into JDK 16, but due to problems with the underlying implementation in Windows 2019 Server, it has been disabled on that platform in this release. The functionality is supported on Linux, MacOS and Windows operating systems whose build number is 18362 or greater. This includes Windows 10 (1903) and newer. More information can be seen in bugs 8259014 and 8252971.

The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: sigset, signal and sigaction. Only sigaction is a cross-platform, supported, API for multi-threaded processes. Both signal and sigset are considered obsolete on those platforms that still define them. Consequently, the use of signal and sigset with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release.

The SunPKCS11 provider has been updated with SHA-3 algorithm support. Additional KeyGenerator support for Hmac using message digests other than SHA-3 has also been added. When the corresponding PKCS11 mechanisms are supported by the underlying PKCS11 library, the SunPKCS11 provider now supports the following additional algorithms:

• MessageDigest: SHA3-224, SHA3-256, SHA3-384, SHA3-512
• Mac: HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512
• Signature: SHA3-224withDSA, SHA3-256withDSA, SHA3-384withDSA, SHA3-512withDSA, SHA3-224withDSAinP1363Format, SHA3-256withDSAinP1363Format, SHA3-384withDSAinP1363Format, SHA3-512withDSAinP1363Format, SHA3-224withECDSA, SHA3-256withECDSA, SHA3-384withECDSA, SHA3-512withECDSA, SHA3-224withECDSAinP1363Format, SHA3-256withECDSAinP1363Format, SHA3-384withECDSAinP1363Format, SHA3-512withECDSAinP1363Format, SHA3-224withRSA, SHA3-256withRSA, SHA3-384withRSA, SHA3-512withRSA, SHA3-224withRSASSA-PSS, SHA3-256withRSASSA-PSS, SHA3-384withRSASSA-PSS, SHA3-512withRSASSA-PSS.
• KeyGenerator: HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512, HmacSHA512/224, HmacSHA512/256, HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512.

The SunJSSE provider now supports the use of the EdDSA signature algorithm. Specifically SunJSSE may use certificates containing EdDSA keys for server side and client side authentication and may use certificates signed with the EdDSA algorithm. Additionally, EdDSA signatures are supported for TLS handshake messages that require digital signatures.

When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output you must explicitly replace the use of these flags with their unified logging equivalent.

A new method toList has been added to the java.util.Stream interface. This introduces a potential source incompatibility with classes that implement or interfaces that extend the Stream interface and that also statically import a toList method from elsewhere, for example, Collectors.toList. References to such methods must be changed to use a qualified name instead of a static import.

The following root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore:

+ alias name "thawtepremiumserverca [jdk]"
  Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

+ alias name "verisignclass2g2ca [jdk]"
  Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

+ alias name "verisignclass3ca [jdk]"
  Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

+ alias name "verisignclass3g2ca [jdk]"
  Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

+ alias name "verisigntsaca [jdk]"
  Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

The stop, destroy, isDestroyed, setDaemon and isDaemon methods defined by java.lang.ThreadGroup have been terminally deprecated in this release.

ThreadGroup::stop is inherently unsafe and has been deprecated since Java 1.2. The method is now terminally deprecated and will be removed in a future release.

The API and mechanism for destroying a ThreadGroup is inherently flawed. The methods that support explicitly or automatically destroying a thread group have been terminally deprecated and will be removed in a future release.

For improved performance, JVM/TI ObjectFree events are no longer posted within GC pauses. The events are still posted as requested, and will be posted before ObjectFree events are enabled or disabled with SetNotificationMode. SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.

TLS 1.0 and 1.1 are versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3).

These versions have now been disabled by default. If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

Locale data based on Unicode Consortium's CLDR has been upgraded to their version 38. For the detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes:

• http://cldr.unicode.org/index/downloads/cldr-38

Module::getPackages returns the set of package names for the packages in this module.

For unnamed modules, the spec and implementation is corrected to return the names of the packages that have been defined in this unnamed module. Prior to Java SE 16, Module::getPackages returns the set of package names for the packages defined to this module's class loader if this module is an unnamed module and the result includes packages in other named modules defined to this module's class loader, if any.

A new formatter pattern letter 'B', and its supporting method is added to java.time.format.DateTimeFormatter/DateTimeFormatterBuilder classes, which translates day periods defined in Unicode Consortium's CLDR (https://unicode.org/reports/tr35/tr35-dates.html#dayPeriods). Applications can now express periods in a day not only just am/pm, but something like "in the morning" or "at night". An example to demonstrate the day periods is as follows:

DateTimeFormatter.ofPattern("B").format(LocalTime.now())

which produces the day period text depending on the time of the day and locale.

The JDK update incorporates tzdata2020d. The main change is

• Palestine ends DST earlier than predicted, on 2020-10-24.

Please refer to https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html for more information.

The behavior of the HttpPrincipal::getName method has been updated to return the name in the correct format as outlined in its specification i.e. "realm:username". Previously, the method incorrectly returned "username" only.

The Java Ahead-of-Time compilation experimental tool jaotc has been removed. Using HotSpot VM options defined by JEP295 will produce a not supported option warning but will otherwise be ignored.

The experimental Java-based JIT compiler, Graal JEP317, has been removed. Attempt to use it will produce JVMCI error: JVMCI compiler 'graal' not found.

The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms which were based on RC2, DESede, and SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.

For compatibility, a new system property named keystore.pkcs12.legacy is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.

The JDK update incorporates tzdata2020c. The main change is

• Fiji starts DST later than usual, on 2020-12-20.

Please refer to https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html for more information.

This enhancement includes two main changes:

1. The JarSigner API and the jarsigner tool now support signing a JAR file with an RSASSA-PSS or EdDSA key.

2. Instead of signing the .SF file directly, jarsigner creates a SignerInfo signedAttributes field which contains ContentType, MessageDigest, SigningTime, and CMSAlgorithmProtection. The field will not be generated if an alternative signing mechanism is specified by the jarsigner -altsigner option. Please note that although this field was not generated by jarsigner before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases.

Prior to JDK 16, ZipOutputStream.putnextEntry() would not recalculate the compressed size for a compressed (DEFLATED) entry. This could result in the ZipException, "invalid entry compressed size", being thrown if the current ZLIB implementation used when ZipOutputStream.putNextEntry() is called differs from the implementation at the time when the entry was added to the original ZIP file.

Starting with JDK 16, if the compressed size has not been explicitly set with the ZipEntry.setCompressedSize(long) method when writing a compressed(DEFLATED) entry, then the compressed size will be set to the actual compressed size after deflation.

The non-public class java.awt.PeerFixer was removed in this release. This class was used to provide deserialization support of ScrollPane objects created prior JDK 1.1.1.

Following the JDK's update to tzdata2020b, the long-obsolete files named pacificnew and systemv have been removed. As a result, the "US/Pacific-New" Zone name declared in the pacificnew data file is no longer available for use.

Information regarding this update can be viewed at https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html

A new JNDI environment property “com.sun.jndi.ldap.tls.cbtype” has been added to enable TLS Channel Binding data in LDAP authentication over SSL/TLS protocol to the Windows AD server. Possible value is “tls-server-end-point” - Channel Binding data is created on the base of the TLS server certificate. See the module description of the java.naming module.

The SunEC provider no longer supports the following elliptic curves that are either obsolete or not implemented using modern formulas and techniques:

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 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

To continue using any of these curves users will need to find third-party alternatives.

When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as JVMTI_HEAP_ROOT_MONITOR or JVMTI_HEAP_REFERENCE_MONITOR) and in heap dumps (reported as HPROF_GC_ROOT_MONITOR_USED). As of this release, a weak reference is used and these are not observable to JVM TI or heap dumps, and consequently JVMTI_HEAP_ROOT_MONITOR, JVMTI_HEAP_REFERENCE_MONITOR and HPROF_GC_ROOT_MONITOR_USED will no longer be reported.

SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters.

In this release, the default HttpClient returns cancelable futures.

The default HttpClient is created by a call to HttpClient.newHttpClient(), or by invoking the build method on builders returned by HttpClient.newBuilder(). The implementation of the sendAsync methods in the default HttpClient now return CompletableFuture objects that are cancelable. Invoking cancel(true) on a cancelable future that is not completed, attempts to cancel the HTTP exchange in an effort to release underlying resources as soon as possible. More information can be obtained by reading the API documentation of the HttpClient::sendAsync methods.

The following APIs have been deprecated:

java.security.cert.X509Certificate.getIssuerDN()
java.security.cert.X509Certificate.getSubjectDN()
java.security.cert.X509CRL.getIssuerDN()
java.security.cert.X509CertSelector.setIssuer(String)
java.security.cert.X509CertSelector.setSubject(String)
java.security.cert.X509CertSelector.getIssuerAsString()
java.security.cert.X509CertSelector.getSubjectAsString()
java.security.cert.X509CRLSelector.addIssuerName(String)

These APIs either take or return Distinguished Names as Principal or String objects which can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs which use X500Principal objects instead.

Creation of an instance of java.net.http.HttpClient may fail with UncheckedIOException if the underlying resources required by the implementation cannot be allocated.

Typically, this may happen if the underlying resources required to opening a java.nio.channels.Selector are not available. In this case Selector.open() will throw an IOException which the default implementation of java.net.http.HttpClient will wrap in an UncheckedIOException. The API documentation of HttpClient.newHttpClient() and HttpClient.newBuilder().build() have been updated to specify that UncheckedIOException may be thrown if the underlying resources required by the implementation cannot be allocated. Prior to this change, an undocumented InternalError would have been thrown.

The following root certificates have been added to the cacerts truststore:

+ SSL Corporation
  + sslrootrsaca
    DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US

  + sslrootevrsaca
    DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US

  + sslrooteccca
    DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US

The following root certificate has been added to the cacerts truststore:

+ Entrust
  + entrustrootcag4
    DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

Case insensitive operations in java.lang.String class now correctly do case insensitive comparisons for supplementary characters (characters which have code point values over U+FFFF). For details, see the updates to the methods:

   - compareToIgnoreCase(String other)
   - equalsIgnoreCase(String other)
   - regionMatches(boolean ignoreCase, ...)

For example,

"ud801udc00".equalsIgnoreCase("ud801udc28")

returns true, because '𐐀' ("ud801udc00") and '𐐨' ("ud801udc28") are equal to each other character in case insensitive comparison.

When signing a file that contains POSIX file permission or symlink attributes, jarsigner now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the jarsigner -verify operation for such files.

Note that the jar tool does not read/write these attributes. This change is more visible to tools like unzip where these attributes are preserved.

In this release java.util.logging.LogRecord is updated to support long thread ids.

LogRecord::getThreadID and LogRecord::setThreadID are deprecated: new accessors LogRecord::getLongThreadID and LogRecord::setLongThreadID are provided and should be used instead.

The serial field threadID has been deprecated and a new serial field longThreadID that can support long values has been introduced. The deprecated threadID field is kept in the serial form for backward compatibility. Long thread ids that are less than Integer.MAX_VALUE are directly mapped to threadID (and longThreadID has the same value). For longThreadID greater than Integer.MAX_VALUE, a new negative value for the int threadID is synthesized, using a deterministic algorithm based on the longThreadID hash, and such that the resulting value is guaranteed to be a negative value.

The deserialization of java.lang.reflect.Proxy objects can be limited by setting the system property jdk.serialProxyInterfaceLimit. The limit is the maximum number of interfaces allowed per Proxy in the stream. Setting the limit to zero prevents any Proxies from being deserialized including Annotations, a limit of less than 2 might interfere with RMI operations.

A new system property, jdk.tls.maxHandshakeMessageSize, has been added to set the maximum allowed size for the handshake message in TLS/DTLS handshaking. The default value of the system property is 32768 (32 kilobytes).

A new system property, jdk.tls.maxCertificateChainLength, has been added to set the maximum allowed length of the certificate chain in TLS/DTLS handshaking. The default value of the system property is 10.

A new environment property, jdk.jndi.ldap.mechsAllowedToSendCredentials, has been added to control which LDAP authentication mechanisms are allowed to send credentials over clear LDAP connections - a connection not secured with TLS. An encrypted LDAP connection is a connection opened by using ldaps scheme, or a connection opened by using ldap scheme and then upgraded to TLS with a STARTTLS extended operation.

The value of the property, which is by default not set, is a comma separated list of the mechanism names that are permitted to authenticate over a clear connection. If a value is not specified for the property, then all mechanisms are allowed. If the specified value is an empty list, then no mechanisms are allowed (except for none and anonymous). The default value for this property is 'null' ( i.e. System.getProperty("jdk.jndi.ldap.mechsAllowedToSendCredentials") returns 'null'). To explicitly permit all mechanisms to authenticate over a clear connection, the property value can be set to "all". If a connection is downgraded from encrypted to clear, then only the mechanisms that are explicitly permitted are allowed.

The property can be supplied to the LDAP context environment map, or set globally as a system property. When both are supplied, the environment map takes precedence.

Note: none and anonymous authentication mechanisms are exempted from these rules and are always allowed regardless of the property value.