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 12

Mark 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

Removed the 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 8

GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() are unified across the platforms (JDK-8214918)

client-libs

In JDK 1.4 two new methods were added to the GraphicsEnvironment class:

Take a look to this descriptions from the link above: "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.)"

The JDK 13 implementation of these methods are unified across the platforms(windows/linux/solaris/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 platform

The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider. (JDK-8217835)

security-libs/javax.net.ssl

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

Legacy applications may have used this 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);).

Since the SunJSSE provider uses the JDK default cryptography providers, as an alternative applications can configure the security.provider security properties to use FIPS 140 compliant cryptography providers instead.

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

The Swing Motif Look and Feel is deprecated and unsupported on macOS (JDK-8177960)

client-libs

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

In the source code it is deprecated with the intent to remove it in some future release. It is recommended to use javax.swing.plaf.metal.MetalLookAndFeel instead.