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 25

Support Kerberos cross-realm referrals (RFC 6806) (JDK-8215032)

security-libs/org.ietf.jgss:krb5

The Kerberos client has been enhanced with the support of principal name canonicalization and cross-realm referrals, as defined by the RFC 6806 protocol extension.

As a result of this new feature, the Kerberos client can take advantage of more dynamic environment configurations and does not necessarily need to know (in advance) how to reach the realm of a target principal (user or service).

Support is enabled by default and 5 is the maximum number of referral hops allowed. To turn it off, set the sun.security.krb5.disableReferrals security or system property to false. To configure a custom maximum number of referral hops, set the sun.security.krb5.maxReferrals security or system property to any positive value.

See further information in JDK-8223172.

Add -XX:SoftMaxHeapSize flag (JDK-8222145)

hotspot/gc

The manageable command-line flag -XX:SoftMaxHeapSize=<bytes> was added. It currently only has an effect when the Z garbage collector is enabled (-XX:+UseZGC).

When set, the GC will strive to not grow the heap beyond the specified size, unless the GC decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not allowed to be set to a value greater than the maximum heap size (-Xmx). When not set on the command-line, it defaults to a value equal to the maximum heap size.

Being manageable, its value can be adjusted at runtime, for example using jcmd VM.set_flag SoftMaxHeapSize <bytes> or through the HotSpot MXBean.

Setting this flag can be useful in a number of situations, for example:

  • In environments where resource usage is a concern, you might want to keep the heap footprint down while also retaining the capability to deal with a temporary increase in heap space requirement.

  • When using a concurrent GC (like ZGC), you might want to play it safe and increase the confidence level that you will not run into an allocation stall because of an unforeseen increase in allocation rate. Setting a soft max heap size would encourage the GC to maintain a smaller heap, which in turn means the GC will collect garbage more aggressively than it otherwise would have, making it more resilient to a sudden increase in the application allocation rate.

SunPKCS11 provider upgraded with support for PKCS#11 v2.40 (JDK-8080462)

security-libs/javax.crypto:pkcs11

The SunPKCS11 provider has been updated with support for PKCS#11 v2.40. This version adds support for more algorithms such as the AES/GCM/NoPadding cipher, DSA signatures using SHA-2 family of message digests, and RSASSA-PSS signatures when the corresponding PKCS11 mechanisms are supported by the underlying PKCS11 library. For more detailed information, please see https://bugs.openjdk.java.net/browse/JDK-8080462.

Build 24

A jrt URI can only encode paths to files in /modules tree (JDK-8224946)

tools/jlink

A jrt URL is a hierarchical URI with syntax jrt:/[$MODULE[/$PATH]]. When using the jrt file system, a java.net.URI object can be created with the java.nio.file.Path::toUri method to encode a normalized path to a file in the /modules tree. A jrt URL cannot encode a path to a file in the /packages tree. The jrt file system provider has changed in this release so that toUri fails with IOError when it is not possible to encode the file path as a jrt URI. This change may impact tools that assuming a URI can be created to locate files in the /packages tree. Tools with paths to files in /packages can use the toRealPath() method to obtain the real path (in /modules) before attempting to convert the file path to a URI.

Improve the behavior of MaxRAM settings and UseCompressedOops (JDK-8222252)

hotspot/gc

The behavior of several GC Heap selection flags have changed to better meet the expectation of users.

Prior to this change, if the heap size selection resulting from the use of these flags exceeded the maximum reachable address when UseCompressedOops is enabled, the heap size would be truncated to be within the CompressedOops range. Also, the percentage or fractional calculation performed was based on the value of MaxRAM and not the amount of physical memory available in the system. Here are the options impacted by this change:

  • -XX:MaxRAMPercentage
  • -XX:MaxRAMFraction
  • -XX:MinRAMPercentage
  • -XX:MinRAMFraction
  • -XX:InitialRAMPercentage
  • -XX:InitialRAMFraction
  • -XX:MaxRAM

The new behavior calculates the percentage or fraction based on the host's available memory unless the user also specifies -XX:MaxRAM. In addition, UseCompressedOops is automatically disabled if the heap size resulting from the use of any of these options, including -XX:MaxRAM, is greater than can be addressed in CompressedOops mode, unless the -XX:+UseCompressedOops option is specified to override this behavior.

Note: This change only impacts 64-bit platforms.

Properties files containing malformed unicode were sometimes misparsed (JDK-8224240)

core-libs/java.util

An IllegalArgumentException is always thrown when loading a properties file with malformed unicode sequences. Previously, such a sequence appearing at the end of a line was being parsed using the contents of the preceding line, which in rare cases meant it could be parsed as a valid but likely incorrect sequence.

Improve ergonomics for Sparse PRT entry size (JDK-8223162)

hotspot/gc

This enhancement changes the ergonomics for sizing the lowest level (most quickly to access, but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.

The number of entries now grow exponentially with region size instead of linearly. This means that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB regions respectively instead of 4/8/12/16/20/24 entries.

With this change, G1 uses significantly less memory for remembered sets for applications requiring a significant amount of remembered sets. This may also result in decreased garbage collection pause times in these cases.

The ergonomically determined values may be overridden using the -XX:G1RSetSparseRegionEntries option as before.

Deprecated rmic tool For Removal (JDK-8217412)

core-libs/java.rmi

The rmic tool has been deprecated and may be removed from a future release. The rmic tool was used to create static stubs that support the Java Remote Method Protocol (JRMP) used by the Java Remote Method Invocation (RMI) facility. Statically generated stubs are obsolete and were replaced by dynamically generated stubs in Java SE 5.0. Dynamically generated stubs no longer require pregeneration using a tool such as rmic, and they are functionally equivalent to statically generated stubs. RMI applications should be migrated to use dynamically generated RMI stubs by changing the way remote objects are exported. See the class documentation for java.rmi.server.UnicastRemoteObject for further details.

DateTimeFormatter now throws DateTimeParseException on Invalid HOUR_OF_AMPM (JDK-8223773)

core-libs/java.time

The parsing behavior of DateTimeFormatter with HOUR_OF_AMPM has changed. It now correctly throws a DateTimeParseException with an out-of-bounds input values, such as 12.

New String constants for Canonical XML 1.1 URIs (JDK-8224767)

security-libs/javax.xml.crypto

New String constants named INCLUSIVE_11 and INCLUSIVE_11_WITH_COMMENTS have been added to the javax.xml.crypto.dsig.CanonicalizationMethod API. These represent the URIs for the Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature.

JEP 353: Reimplement the Legacy Socket API (JDK-8221481)

core-libs/java.net

The underlying implementation for the java.net.Socket and java.net.ServerSocket APIs has been replaced in this release. JEP 353 provides all the details on this change.

Every effort has been made to ensure that the new implementation is compatible with the old implementation but it is possible that there is existing code that depends on unspecified behavior in corner cases where the old and new implementations behave differently. The JDK continues to include the old implementation (known as "PlainSocketImpl" or the "plain" implementation) to allow such code continue to run. The old implementation is selected by running with the system property "jdk.net.usePlainSockteImpl" set, or set to the value "true", i.e. run with -Djdk.net.usePlainSocketImpl or -Djdk.net.usePlainSocketImpl=true. The property can also be configured in the JDK network configuration file, located in ${java.home}/conf/net.properties. The old implementation, and the system property to select the old implementation, will be removed in a future release.

Build 23

Default implementation of SocketImpl methods supportedOptions, getOption, setOption changed (JDK-8224477)

core-libs/java.net

The default implementation of the supportedOptions(), getOption(SocketOption<T>) and setOption(SocketOption<T>, T) methods, defined by java.net.SocketImpl and java.net.DatagramSocketImpl, have changed in this release. The default implementation of the supportedOptions() methods have been changed to return an empty set. The default implementations of the getOption(SocketOption<T>) and setOption(SocketOption<T>, T) methods have been changed to throw UnsupportedOperationException.

Developers extending java.net.SocketImpl or java.net.DatagramSocketImpl to create their own socket or datagram socket implementations need to override these methods to support the socket options that the custom socket implementation supports.

[xmldsig] Add KeyValue::EC_TYPE (JDK-8223053)

security-libs/javax.xml.crypto

The ECKeyValue type as described in the W3C Recommendation for XML-Signature Syntax and Processing is now supported. A new EC_TYPE constant has been added to the javax.xml.crypto.dsig.keyinfo.KeyValue interface. Please note that only the NamedCurve domain parameter type is currently supported, and the ECParameters explicit curve parameter type is not supported.

Support for Unicode 12.1 (JDK-8221431)

core-libs/java.util:i18n

This release upgrades Unicode support to 12.1 which includes the following:

  • java.lang.Character supports Unicode Character Database of 12.1 level, in which 12.0 adds 554 characters since 11.0, for a total of 137,928 characters. These additions include 4 new scripts, for a total of 150 scripts, as well as 61 new emoji characters. 12.1 adds exactly one character, U+32FF SQUARE ERA NAME REIWA, since 12.0.
  • java.text.Bidi and java.text.Normalizer classes support 12.0 level of Unicode Standard Annexes, #9 and #15, respectively.
  • java.util.regex package supports Extended Grapheme Clusters based on 12.0 level of Unicode Standard Annex #29

Build 22

Dynamic CDS Archiving (JDK-8207812)

hotspot/runtime

JEP 350 extends application class-data sharing (AppCDS) to allow the dynamic archiving of classes as a Java application is exiting. It also improves the usability of AppCDS by eliminating the need for users to do trial runs to create a class list for each application. The existing static archiving enabled by the -Xshare:dump option, using a class list, continues work as is.

The dynamically-generated archive is created on top of the default system archive packaged with the running JDK image. A separate top-layer archive file is generated for each application. The user can specify the filename of the dynamic archive name as the argument to the -XX:ArchiveClassesAtExit option. For example, the following command creates hello.jsa:

    % bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello

To run the same application using this dynamic archive:

    % bin/java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello

The user could also specify both the base and the dynamic archives in the -XX:SharedArchiveFile option such as:

    -XX:SharedArchiveFile=<base archive>:<dynamic archive>

[CSR JDK-8221706](https://bugs.openjdk.java.net/browse/JDK-8221706) has more details on the command line option.

New methods for creating DOM and SAX factories with Namespace support (JDK-8219692)

xml/jaxp

New methods has been added for instantiating DOM and SAX factories with Namespace support by default. These methods are prefixed over their existing counterparts with "NS" that stands for NamespaceAware. Below is a list of the new methods:

  • newDefaultNSInstance()
  • newNSInstance()
  • newNSInstance(String factoryClassName, ClassLoader classLoader)

Using these new methods, a parser created through the factory will be NamespaceAware by default. For example, the following statement:

DocumentBuilder db = DocumentBuilderFactory.newDefaultNSInstance().newDocumentBuilder(); 

is equivalent to:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance(); 
dbf.setNamespaceAware(true); 
DocumentBuilder db = dbf.newDocumentBuilder();

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

Build 21

Bad EnclosingMethod attribute on classes declared in lambdas (JDK-8215470)

tools/javac

If an anonymous or local inner class is declared inside of a lambda, the EnclosingMethod attribute on that class refers to the synthetic lambda method rather than the method that enclosed the original declaration. The original method should be considered as the closest lexically enclosing method.

The proposed solution to this issue is to point the EnclosingMethod attribute of inner classes declared inside a lambda to the original enclosing method. The Java compiler was updated so that the EnclosingMethod attribute of anonymous or local inner classes declared inside a lambda point to the method enclosing the declaration.

This is the related section in the Java Language Specification: JVMS 11 4.7.7: It is the responsibility of a Java compiler to ensure that the method identified via the method_index is indeed the closest lexically enclosing method of the class that contains this EnclosingMethod attribute.

The "awt.toolkit" system property has been removed. (JDK-8212700)

client-libs

Historically (up to JDK 1.8) documentation for the java.awt.Toolkit class referred to the "awt.toolkit" system property, which was set to the name of the platform implementation subclass. The documentation of this property was removed in JDK 9 since it was internal detail and was not meant to be a supported interface and encapsulation by the module system meant the class could not be manipulated directly However the system property was not removed until now. Applications which previously read this property can still, if necessary, obtain it by instantiating the AWT Toolkit and querying the class name via that instance.

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.

Upgrade CLDR to Version 35.1 (JDK-8221432)

core-libs/java.util:i18n

Locale data based on Unicode Consortium's CLDR has been upgraded to their version 35.1 which includes several localized display names for the Japanese new era, Reiwa. There are some notable locale data changes, such as year formatting in Dutch locale (JDK-8225240), or French grouping separator change (JDK-8225245). For the detailed locale data changes, please refer to the cumulative CLDR changes from the previously supported version v.33. Here are the links to each CLDR upgrade release: CLDR 33.1: http://cldr.unicode.org/index/downloads/cldr-33-1 CLDR 34: http://cldr.unicode.org/index/downloads/cldr-34 CLDR 35, 35.1: http://cldr.unicode.org/index/downloads/cldr-35

Build 20

Drop support for pre JDK 1.4 SocketImpl implementations (JDK-8216978)

core-libs/java.net

Support for custom java.net.SocketImpl implementations compiled for Java SE 1.3 and older has been removed in this release. This change has no impact on SocketImpl implementations compiled for Java SE 1.4 (released in 2002) or newer.

Add Add FileSystems.newFileSystem(Path, Map<String, ?>) method (JDK-8218875)

core-libs/java.nio

Three new methods have been added to java.nio.file.FileSystems in this release to make it easier to use file system providers that treat the contents of a file as a file system.

  • newFileSystem(Path)
  • newFileSystem(Path, Map<String, ?>)
  • newFileSystem(Path, Map<String, ?>, ClassLoader)

The addition of newFileSystem(Path, Map<String, ?>) creates a source (but not binary) compatibility issue for code that has been using the existing 2-arg newFileSystem(Path, ClassLoader) and specifying the class loader as null, e.g. the following can not be compiled because the reference to newFileSystem is ambiguous:

FileSystem fs = FileSystems.newFileSystem(path, null);

This code needs to be modified to cast the second parameter to java.lang.ClassLoader to avoid the ambiguous reference.

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

ZGC: Maximum Heap Size Increased to 16TB (JDK-8221786)

hotspot/gc

The maximum supported heap size for ZGC was increased from 4TB to 16TB.

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

Files.createSymbolicLink can be used in "Developer Mode" without additional privileges (JDK-8218418)

core-libs/java.nio

On Microsoft Windows, java.nio.file.Files.createSymbolicLink has been changed so that it can now be used to create symbolic links when the process is not elevated but the user is running in "Developer Mode". This may be useful for tools and other development time tasks that need to create symbolic links without requiring additional privileges.

New Reiwa Era Support (JDK-8174268)

core-libs/java.time

This release adds support for the Japanese era public field JapaneseEra.REIWA. 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 14

Improved Handling of the "Class-Path" JAR Manifest Attribute (JDK-8211941)

core-libs

The JAR file specification has been updated to clarify what constitutes a valid entry for the Class-Path JAR Manifest Attribute. See the JAR file specification for further details.

Invalid entries are now ignored. Applications relying on invalid Class-Path entries may see a ClassNotFoundException. A system property has been added to aid in debugging of the Class-Path attribute. When the "jdk.net.URLClassPath.showIgnoredClassPathEntries" property is set to true, invalid Class-Path entries will be printed to the console.

Lookup.unreflectSetter(Field) now throws IllegalAccessException for static final fields (JDK-8216558)

core-libs/java.lang.invoke

java.lang.invoke.MethodHandles.Lookup::unreflectSetter returns a MethodHandle giving write access to the given Field object. A Field object for a static final field does not have write access even if its accessible flag is true (i.e. Field.setAccessibe(true) has been called). In JDK 13, Lookup::unreflectSetter is fixed to throw IllegalAccessException if the given Field object is a static final field.

Build 13

Change to ServerSocket.accept() when the system-wide factory for client or server socket implementations is set (JDK-8220493)

core-libs/java.net

Developers using the java.net.Socket.setSocketImplFactory or java.net.ServerSocket.setSocketFactory APIs to change the system-wide factories for client socket or server socket implementations should take note of the following changes in this release.

  1. Invoking ServerSocket::accept on a ServerSocket using a system-default SocketImpl to accept a connection will always return a Socket with a system-default SocketImpl. The system-wide factory for client socket implementations will not be invoked to create the client socket implementation in this case.

  2. java.net.ServerSocket::implAccept has been changed to disallow a ServerSocket using a system-default SocketImpl from accepting a connection with a Socket using a custom SocketImpl. It has also been changed to disallow a ServerSocket using a custom SocketImpl to accept a connection with a Socket using a system-default SocketImpl. Disallowing these nonsensical combinations of SocketImpl improves reliability in cases where an application sets one, but not both, socket implementation factories.

The changes should have no impact on applications that set the same factory for both client and server socket implementations.

JNI NewDirectByteBuffer creates direct buffer that is java.nio.ByteOrder.BIG_ENDIAN (JDK-5043362)

core-libs/java.nio

The Java Native Interface (JNI) specification has been clarified in this release to specify that the NewDirectByteBuffer function creates a direct buffer that is always big-endian (high byte first; java.nio.ByteOrder.BIG_ENDIAN). This aligns the specification with long standing behavior (JDK 1.4, released in 2002) so it does not affect existing code.

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

New java.nio.ByteBuffer bulk get/put methods to transfer bytes without regard to buffer position (JDK-5029431)

core-libs/java.nio

java.nio.ByteBuffer and the other buffer types in java.nio now define absolute bulk get and put methods to transfer contiguous sequences of bytes without regard to or effect on the buffer position.

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 JDK 13 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 5

Files.isHidden may returns true for hidden directories on Windows (JDK-8215467)

core-libs/java.nio

On Microsoft Windows, the java.nio.file.Files.isHidden method has historically ignored the DOS "hidden" attribute on directories. This has been fixed in this release so that isHidden now returns true when invoked to test a directory that has this attribute set.

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

VM option -XX:+AggressiveOpts removed (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.

Build 2

javap checksum uses SHA-256 (JDK-8225748)

tools/javap

javap includes a checksum of the contents of the class file in verbose output. The checksum is now calculated with the SHA-256 algorithm, instead of the older MD5 algorithm.

Not Yet Integrated

JEP 354: Switch Expressions (Preview) (JDK-8222184)

tools/javac

Extend switch so it can be used as either a statement or an expression, and so that both forms can use either traditional case ... : labels (with fall through) or new case ... -> labels (with no fall through), with a further new statement for yielding a value from a switch expression. These changes will simplify everyday coding, and prepare the way for the use of pattern matching (JEP 305) in switch. This is a preview language feature in JDK 13.

Support X25519 and X448 in TLS (JDK-8224520)

security-libs/javax.net.ssl

The named elliptic curve groups x25519 and x448 are now available for JSSE key agreement in TLS versions 1.0 to 1.3, with x25519 being the most preferred of the default enabled named groups. The default ordered list is now:

    x25519, secp256r1, secp384r1, secp521r1, x448,
    sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1,
    secp256k1,
    ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192

The default list can be overridden using the system property jdk.tls.namedGroups.

Delivered

Add support for MS Cryptography next generation (CNG) (JDK-8026953)

security-libs/javax.crypto

The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG) format. This means RSA and EC keys in CNG format are loadable from Windows keystores like "Windows-MY". Signature algorithms related to EC (SHA1withECDSA, SHA256withECDSA etc.) are also supported.

JEP 351: ZGC: Uncommit Unused Memory (JDK-8220347)

hotspot/gc

ZGC was enhanced to return unused heap memory to the operating system. This is useful for applications and environments where memory footprint is a concern.

This feature is enabled by default, but can be explicitly disabled using -XX:-ZUncommit. Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum heap size (-Xms). This means this feature will be implicitly disabled if the minimum heap size (-Xms) is configured to be equal to the maximum heap size (-Xmx).

An uncommit delay can be configured using -XX:ZUncommitDelay=<seconds> (defaults to 300 seconds). This delay specifies for how long memory should have been unused before it's eligible for uncommit.

For more details, see (JEP 351).

Old Features Removed from javadoc Tool (JDK-8215608)

tools/javadoc(tool)

The following four features have been removed from the javadoc tool:

Support for generating API documentation using HTML 4: Support for HTML 5 was added in JDK 9 and has been the default since JDK 11. To generate API documentation that is fully compliant with the HTML 5 specification, developers should ensure that any use of HTML tags in their documentation comments is also compliant with the HTML 5 specification.

Support for the "old" javadoc API: This includes the API (com.sun.javadoc), the old standard doclet (com.sun.tools.doclets.standard), and the old entry point (com.sun.tools.javadoc.Start), all in the jdk.javadoc module. A new API and a new standard doclet were introduced in JDK 9, leveraging other modern modeling API such as javax.lang.model. The javadoc tool can be programmatically invoked using the javax.tools.DocumentationTool API, or (for simple use) java.util.spi.ToolProvider. Users that just use the javadoc tool to generate standard API documentation are not affected.

Support for generating documentation using HTML frames: It has been replaced by the "Search" feature, added in JDK 9, and by improved index files and links within pages.

Support for the --no-module-directories option: This option provided limited support for the organization used for the generated documentation by the javadoc tool in JDK 9 and 10, in which the files for different modules were not grouped into separate directories.