JDK 14 Early-Access Release Notes

This is a draft of the release notes that will accompany JDK 14. The contents are subject to change until release.

Build 22

Thread.countStackFrames changed to unconditionally throw UnsupportedOperationException (JDK-8205132)

core-libs/java.lang

The terminally deprecated method Thread.countStackFrames has changed in this release to unconditionally throw UnsupportedOperationException.

This method will be removed in a future release.

Build 21

Upgrade CLDR to v36 (JDK-8231273)

core-libs/java.util:i18n

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

DelegationPermission allows to create an instance that thows NPE on ::equals call (JDK-8231196)

security-libs/javax.security

When a DelegationPermission object is created and the principals argument does not contain a pair of principals, an IllegalArgumentException is now thrown.

Thread suspend/resume are now deprecated for removal (JDK-8231602)

core-libs/java.lang

The following methods related to thread suspension in java.lang.Thread and java.lang.ThreadGroup have been terminally deprecated in this release:

  • Thread.suspend()
  • Thread.resume()
  • ThreadGroup.suspend()
  • ThreadGroup.resume()
  • ThreadGroup.allowThreadSuspension(boolean)

These methods will be removed in a future release.

Build 18

DatagramChannel.disconnect may leave the channel's socket in an unspecified state (JDK-8231260)

core-libs/java.nio

The DatagramChannel implementation has been updated in this release so that the disconnect method attempts to workaround Linux kernel behavior that reverts the local port to 0 after dissolving the association. The issue arises when a DatagramChannel is initially bound to an ephemeral port, connected (by calling its connect method), and then disconnected (by calling its disconnect method). The workaround in the DatagramChannel::disconnect is to attempt to re-bind the channel's socket to its original port. This will usually succeed but if it fails then IOException will be thrown. This workaround has been used in the DatagramSocket implementation for several releases.

As part of this change, the javadoc for DatagramChannel::disconnect has been updated with an API note to make it clear that an IOException may leave the channel's socket in an unspecified state. The API note also strongly recommends that the channel be closed when disconnect fails.

Build 16

DnsClient TCP socket timeout (JDK-8228580)

core-libs/javax.naming

The semantics of the com.sun.jndi.dns.timeout.initial property of the JNDI DNS provider implementation have been amended. The value of this timeout now uniformly applies to both UDP and TCP queries. Previously it applied only to UDP queries.

New Method to SAX ContentHandler for Handling XML Declaration (JDK-8230814)

xml/jaxp

A new method declaration is added to SAX ContentHandler in this release to receive notification of the XML declaration. Implementing this method, applications will be able to receive the values of version, encoding, and standalone attributes exactly as declared in the input document.

Build 14

MethodType::fromMethodDescriptorString requires "getClassLoader" permission (JDK-8229785)

core-libs/java.lang.invoke

MethodType::fromMethodDescriptorString is changed in this release that when security manager is present and loader parameter is null, it will perform RuntimePermission("getClassLoader") security permission check. This is to ensure that access to the system class loader is permitted.

Existing code that calls MethodType.fromMethodDescriptorString(desc, null) may get SecurityException if access the system class loader is denied. The security policy will need to be configured to grant the permission. Applications running without security manager or with non-null loader is not impacted by this change.

Removal of sun.nio.cs.map system property (JDK-8229960)

core-libs/java.nio.charsets

The system property sun.nio.cs.map, added in JDK 1.4.1, has been removed. It was provided for applications to help migrate from old definition of Shift_JIS which was equivalent to MS Windows codepage 932, to the one that is defined by IANA. Applications that are using the mapping property will need to designate the correct charset name based on their needs.

Default ErrorListener No Longer Reports Warnings and Errors to the Console (JDK-8228854)

xml/javax.xml.transform

Prior to this release, the javax.xml.transform.ErrorListener specification defined that the default ErrorListener implementation reported warnings and errors to System.err, and System.out in some cases. This requirement has been removed as of this release and the default ErrorListener now takes no action for warnings and recoverable errors; and in the case of a severe error, throws a TransformerException.

It is recommended that applications always register their own ErrorListener to ensure proper handling of warnings and errors.

Build 12

CDS behavior change with non-existent files during archive creation time (JDK-8227370)

hotspot/runtime

In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in the classpath that do not exist.

At CDS archive dump time, all non-existent elements in the classpath are automatically stripped. E.g., if the command is

java -cp nosuchfile.jar:hello.jar -Xshare:dump 
     -XX:SharedClassListFile=hello.classlist 
     -XX:SharedArchiveFile=hello.jsa

After removing the non-existing elements, the classpath recorded in hello.jsa becomes "hello.jar".

Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath are ignored. With the above example, all of the following commands will successfully load the archive:

(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

Whereas in JDK 13 and before, only (1) is allowed; (2) and (3) would trigger an error.

Build 10

Accounting currency format support (JDK-8215181)

core-libs

Currency format instances with accounting style, in which the amount is formatted in parentheses in some locales, can be obtained by calling NumberFormat.getCurrencyInstance(Locale) with "u-cf-account" Unicode locale extension. Refer to CLDR's accounting currency format style for additional information.

Turn off AOT by default and change related flags to experimental (JDK-8227439)

hotspot/compiler

Following AOT support related flags have been made experimental: UseAOT, PrintAOT and AOTLibrary. Also default value of UseAOT has been changed from enabled to disabled.

Build 8

SunJCE provider now throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding (JDK-8180392)

security-libs/javax.crypto

Prior to this release, the SunJCE provider incorrectly returned a Cipher instance for the "AES/GCM/NoPadding" transformation when a caller requested "AES/GCM/PKCS5Padding". The SunJCE provider now throws NoSuchAlgorithmException when "AES/GCM/PKCS5Padding" is requested. If you are impacted by this issue, the workaround is to use "AES/GCM/NoPadding" instead.

Removed Deprecated java.security.acl APIs (JDK-8191138)

security-libs/java.security

The deprecated java.security.acl APIs have been removed. This includes the the following classes in that package: Acl, AclEntry, AclNotFoundException, Group, LastOwnerException, NotOwnerException, Owner, and Permission.

Removal of netscape.javascript.JSObject::getWindow Method (JDK-8222563)

deploy

The obsolete netscape.javascript.JSObject::getWindow method has been removed. This method was deprecated in JDK 9. As of JDK 11, there is no longer a useful way to use this method; it always returns null.

Not Yet Integrated

Text Visibility Issues in macOS Dark Mode (JDK-8228555)

client-libs

A number of bugs have been reported against Dark Mode on macOS which require a fix in the JavaRuntimeSupport framework (JRS); an issue has been filed with Apple:

FB6798883: The JavaRuntimeSupport.framework does not work properly in Dark Mode

See JDK-8231386 and JDK-8228555 for examples of issues caused by this bug.