JDK 13 Early-Access Release Notes

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

Build 21

Removal of two Comodo root CA certificates (JDK-8222136)

security-libs/java.security

Two Comodo root CA certificates are expired and have been removed from the cacerts keystore:

  • alias name "utnuserfirstclientauthemailca [jdk]"

    Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US

  • alias name "utnuserfirsthardwareca [jdk]"

    Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US

Configurable Read Timeout for CRLs (JDK-8191808)

security-libs/java.security

The com.sun.security.crl.readtimeout system property sets the maximum read timeout for CRL retrievals, in seconds. If the property has not been set, or if its value is negative, it is set to the default value of 15 seconds. A value of 0 means an infinite timeout.

Build 19

Removal of T-Systems Deutsche Telekom Root CA 2 Certificate (JDK-8222137)

security-libs/java.security

The T-Systems Deutsche Telekom Root CA 2 certificate is expired and has been removed from the cacerts keystore:

  • alias name "deutschetelekomrootca2 [jdk]"

    Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE

Build 17

javac rejects classfiles with broken EnclosingMethod attribute (JDK-8215407)

tools/javac

javac now rejects classfiles that have an invalid EnclosingMethod attribute, in which the name of enclosing class is not a prefix of the name of the current class, as required by JLS 13.1.

Build 16

Update the default enabled cipher suites preference (JDK-8163326)

security-libs/javax.net.ssl

The preference of the default enabled cipher suites has been changed. The compatibility should be minimal. Applications could customize enabled cipher suites and the preference if needed. For more details, please refer to the SunJSSE provider documentation and the JSSE Reference Guide documentation.

Build 15

New Reiwa Era Support (JDK-8174268)

core-libs

This release adds support for the Reiwa Japanese era. Check the javadoc for further details.

Duplicated RSA Services no Longer Supported by SunJSSE Provider (JDK-8220016)

security-libs

Support for RSA KeyFactory, RSA KeyPairGenerator, MD2withRSA, MD5withRSA, and SHA1withRSA Signature has been removed from SunJSSE provider.

Since JDK 5, SunRsaSign provider was introduced to support these RSA-related algorithms. The only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK 5 applications. Removal should only impact applications that explicitly request these RSA services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider name.

Use server cipher suites preference by default (JDK-8168261)

security-libs/javax.net.ssl

For TLS connections, by default, the cipher suite selection is updated to use the server cipher suites preference. Applications can configure the behavior with the SSLParameters.setUseCipherSuitesOrder​() method.

Deprecated and Unsupported Swing Motif Look and Feel on macOS (JDK-8177960)

client-libs

Swing Motif Look and Feel is unsupported on macOS in JDK 13.

In the source code, Swing Motif Look and Feel is deprecated with the intent to remove it in a future release. Use javax.swing.plaf.metal.MetalLookAndFeel instead.

New Japanese Era Name: Reiwa (JDK-8205432)

core-libs/java.time

An instance representing the new Reiwa era has been added to this update. Unlike other eras, there is no public field for this era. It can be obtained by calling JapaneseEra.of(3) or JapaneseEra.valueOf("Reiwa"). JDK 13 and later will have a new public field to represent this era.

The placeholder name, "NewEra", for the Japanese era that started from May 1st, 2019 has been replaced with the new official name. Applications that relied on the placeholder name (see JDK-8202088) to obtain the new era singleton (JapaneseEra.valueOf("NewEra")) will no longer work.

Build 13

Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation (JDK-8218723)

security-libs/javax.crypto

The SunJCE implementation of the PBKDF2 SecretKeyFactory will now exclusively use the SunJCE Mac service for the underlying pseudorandom function (PRF). This fixes an issue where 3rd party JCE providers in rare cases could cause the SunJCE PBKDF2 SecretKeyFactory's underlying pseudorandom function (PRF) to fail on Mac.init().

Build 12

Deprecated javax.security.cert APIs with forRemoval=true (JDK-8160247)

security-libs/javax.net.ssl

The javax.security.cert API has been deprecated and marked for removal. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements.

Build 11

Removal of Internal Package com.sun.net.ssl (JDK-8215430)

security-libs/javax.net.ssl

The internal package com.sun.net.ssl has been removed from the SunJSSE provider. The legacy provider name "com.sun.net.ssl.internal.ssl.Provider" is still supported for compatibility. Specifying a provider name is not usually necessary; however, if it is specified, "SunJSSE" should be used for new applications (for example, "SSLContext.getInstance("TLS", "SunJSSE")").

StringBuffer(CharSequence) and StringBuilder(CharSequence) throw NegativeArraySizeException for negatively sized argument (JDK-8218228)

core-libs/java.lang

The behavior of StringBuffer(CharSequence) and StringBuilder(CharSequence) is changed for the argument reporting negative length. The constructors were inconsistently throwing either NegativeArraySizeException or IndexOutOfBoundException. The new behavior is to always throw NegativeArraySizeException for any argument reporting negative length.

Build 10

NullPointerException in java.util.logging.Handler#isLoggable (JDK-8216363)

core-libs/java.util.logging

The default implementation of java.util.logging.Handler.isLoggable is updated to match its specification, and to return false if the record parameter is null. The implementation of java.util.logging.MemoryHandler.isLoggable and java.util.logging.MemoryHandler.publish will no longer throw NullPointerException if the record parameter is null which conforms to their specification.

Build 9

Deprecated Java Options -Xverify:none and -noverify (JDK-8214719)

hotspot/runtime

The Java options -Xverify:none and -noverify have been deprecated in this release. The options will continue to work as intended in this release but will generate the following warning when used:

 warning: Options -Xverify:none and -noverify were deprecated in version 13.0 and will likely be removed in a future release.

Deprecating these options helps prevent users from running code that violates the JVM Specification, which can leave their applications open to malicious code.

Users who need to run without startup verification can use AppCDS to archive their classes. The classes will get verified during archiving and so avoid verification at runtime.

Note that if you encounter issues while using either of these options, it is very likely that you will be required to reproduce the problem without using these options before Oracle Support can assist with an investigation.

Build 8

GraphicsEnvironment.getCenterPoint() and getMaximumWindowBounds() are Unified Across Platforms (JDK-8214918)

client-libs

Two methods were added to the GraphicsEnvironment class in JDK 1.4:

  • getCenterPoint()
  • getMaximumWindowBounds()

See https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering.

The page in the preceding link includes the following description:

"X-Window, Xinerama All monitors share a single virtual coordinate space, as on Microsoft Windows. However, it is possible for the user to specify through X resources where windows should be centered. If these resources are set, getCenterPoint reflects their value. Otherwise, it returns the point at the center of the virtual coordinate space. (In practice, this will almost always be set - CDE sets it by default.)"

Now, in JDK 13, the implementation of getCenterPoint() and getMaximumWindowBounds() has been unified across the platforms (Windows, Linux, Solaris, and macOS):

  • getCenterPoint returns the coordinates of the center of the primary display, for all platforms.
  • getMaximumWindowBounds returns the bounds of the primary display minus display insets, for all platforms.

Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider (JDK-8217835)

security-libs/javax.net.ssl

The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.

Legacy applications might have used the experimental mode with one of the following approaches:

  1. Updating the java.security file and specifying a crypto provider for the SunJSSE provider (for example, security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS)
  2. Using the JDK internal class and creating a provider with a specified crypto provider (for example, new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);).

Because the SunJSSE provider uses JDK default cryptography providers, applications can configure the security.provider security properties to use the FIPS 140 compliant cryptography providers.

Build 7

Change DOM parser to not resolve EntityReference and add Text node with DocumentBuilderFactory.setExpandEntityReferences(false) (JDK-8206132)

xml/javax.xml.parsers

The implementation of the feature ExpandEntityReferences is changed to comply with the specification of the method DocumentBuilderFactory.setExpandEntityReferences. In particular, when the method is set to false and upon encountering an entity reference, a DOM parser created by the DocumentBuilderFactory will only add the EntityReference node to the DOM tree without the expanded Text node. Before the change, the implementation incorrectly added both nodes.

With the change, the DOM parser no longer reads and resolves any entity references when the feature ExpandEntityReferences is set to false. For applications that intend to avoid resolving entity references, it will work as expected.

This change affects also the DOM Load and Save parser. The entities parameter is aligned with the ExpandEntityReferences feature, that is, setting entities parameter to true is equivalent to setting ExpandEntityReferences to false. In the following code snippet, the document will contain EntityReference nodes but not expanded Text nodes:

        LSParser domParser = domImplementationLS.createLSParser(MODE_SYNCHRONOUS, null);
        domParser.getDomConfig().setParameter("entities", true);
        LSInput src = domImplementationLS.createLSInput();
        src.setStringData(source);
        Document document = domParser.parse(src);

When the document is serialized therefore, the resulting string will contain entity references without the text since the references are not resolved:

        LSSerializer lsSerializer = domImplementationLS.createLSSerializer();
        lsSerializer.getDomConfig().setParameter("format-pretty-print", true);
        String result = lsSerializer.writeToString(document);

Build 6

Base64.Encoder and Base64.Decoder methods can throw OutOfMemoryError (JDK-8210583)

core-libs/java.util

The behavior of Base64.Encoder.encode and Base64.Decoder.decode methods are changed for large arrays. The methods were previously throwing an unspecified exception, for example, NegativeArraySizeException. The new behavior throws an OutOfMemoryError if encode and decode methods fail to allocate the output array/buffer or memory.

Build 4

Correct UnicodeDecoder U+FFFE handling (JDK-8216140)

core-libs/java.nio.charsets

The behavior on decoding the code point U+FFFE in the middle of the buffer has been corrected for StandardCharsets.UTF_16[LE/BE]. The decoders have been reporting the code point as "malformed", they now pass through the code point in order to conform to the Unicode Consortium's Corrigendum#9.

Build 3

Remove -XX:+AggressiveOpts (JDK-8216188)

hotspot/runtime

The VM option -XX:+AggressiveOpts was deprecated in JDK 11 and support for it was removed in JDK 12 (where its use was ignored other than generating a warning). Use of this flag will now cause an error on VM initialization.

Not Yet Integrated

Removal of two DocuSign root CA certificates (JDK-8223499)

security-libs/java.security

Two DocuSign root CA certificates are expired and have been removed from the cacerts keystore:

  • alias name "certplusclass2primaryca [jdk]"

    Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR

  • alias name "certplusclass3pprimaryca [jdk]"

    Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR