The Windows implementation of java.io.File allows access to NTFS Alternate Data Streams (ADS) by default. Such streams have a structure like “filename:streamname”. A system property jdk.io.File.enableADS has been added to control this behavior. To disable ADS support in java.io.File, the system property jdk.io.File.enableADS should be set to false (case ignored). Stricter path checking however prevents the use of special devices such as NUL:

SunPKCS11 provider is enhanced to support the following crypto services and algorithms when the underlying PKCS11 library supports the corresponding PKCS#11 mechanisms:

ChaCha20 KeyGenerator <=> CKM_CHACHA20_KEY_GEN mechanism

CHACHA20-POLY1305 Cipher <=> CKM_CHACHA20_POLY1305 mechanism  
CHACHA20-POLY1305 AlgorithmParameters <=> CKM_CHACHA20_POLY1305 mechanism  
CHACHA20 SecretKeyFactory <=> CKM_CHACHA20_POLY1305 mechanism

New TLS cipher suites using the ChaCha20-Poly1305 algorithm have been added to JSSE. These cipher suites are enabled by default. The TLS_CHACHA20_POLY1305_SHA256 cipher suite is available for TLS 1.3. The following cipher suites are available for TLS 1.2:

• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Refer to the "Java Secure Socket Extension (JSSE) Reference Guide" for details on these new TLS cipher suites.

Three processing limits have been added to the XML libraries. These are:

• jdk.xml.xpathExprGrpLimit

Description: Limits the number of groups an XPath expression can contain.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10.

• jdk.xml.xpathExprOpLimit

Description: Limits the number of operators an XPath expression can contain.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 100.

• jdk.xml.xpathTotalOpLimit

Description: Limits the total number of XPath operators in an XSL Stylesheet.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10000.

Supported processors

• jdk.xml.xpathExprGrpLimit and jdk.xml.xpathExprOpLimit are supported by the XPath processor.

• All three limits are supported by the XSLT processor.

Setting properties

For the XSLT processor, the properties can be changed through the TransformerFactory. For example,

        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");

For both the XPath and XSLT processors, the properties can be set through the system property and jaxp.properties configuration file located in the conf directory of the Java installation. For example,

        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");

or in the jaxp.properties file,

        jdk.xml.xpathExprGrpLimit=20

There are two known issues:

1. An XPath expression that contains a short form of the parent axis ".." can return incorrect results. See JDK-8284920 for details.
2. An invalid XPath expression that ends with a relational operator such as ‘<’ ‘>’ and ‘=’ will cause the processor to erroneously throw StringIndexOutOfBoundsException instead of XPathExpressionException. See JDK-8284548 for details.

On macOS, only certificates with proper trust settings in the user keychain will be exposed as trusted certificate entries in the KeychainStore type of keystore. Also, calling the KeyStore::setCertificateEntry method or the keytool -importcert command on a KeychainStore keystore now fails with a KeyStoreException. Instead, call the macOS "security add-trusted-cert" command to add a trusted certificate into the user keychain.

The parsing of URLs in the LDAP, DNS, and RMI built-in JNDI providers has been made more strict. The strength of the parsing can be controlled by system properties:

  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict"    (to control "ldap:" URLs)

  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict"     (to control "dns:" URLs)
  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict"     (to control "rmi:" URLs)

The default value is "compat" for all of the three providers.

• The "legacy" mode turns the new validation off.
• The "compat" mode limits incompatibilities.
• The "strict" mode is stricter and may cause regression by rejecting URLs that an application might consider as valid.

In "compat" and "strict" mode, more validation is performed. As an example, in the URL authority component, the new parsing only accepts brackets around IPv6 literal addresses. Developers are encouraged to use java.net.URI constructors or its factory method to build URLs rather than handcrafting URL strings.

If an illegal URL string is found, a java.lang.IllegalArgumentException or a javax.naming.NamingException (or a subclass of it) is raised.