RELEASE NOTES: JDK 11.0.3

New Japanese Era Name: Reiwa

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.

Square Character Support for Japanese New Era

The code point, U+32FF, is reserved by the Unicode Consortium to represent the Japanese square character for the new era that begins from May, 2019. Relevant methods in the Character class return the same properties as the existing Japanese era characters (e.g., U+337E for "Meizi"). For details about the code point, see http://blog.unicode.org/2018/09/new-japanese-era.html.

Distrust TLS Server Certificates Anchored by Symantec Root CAs

The JDK will stop trusting TLS Server certificates issued by Symantec, in line with similar plans recently announced by Google, Mozilla, Apple, and Microsoft. The list of affected certificates includes certificates branded as GeoTrust, Thawte, and VeriSign, which were managed by Symantec.

TLS Server certificates issued on or before April 16, 2019 will continue to be trusted until they expire. Certificates issued after that date will be rejected. See the DigiCert support page for information on how to replace your Symantec certificates with a DigiCert certificate (DigiCert took over validation and issuance for all Symantec Website Security SSL/TLS certificates on December 1, 2017).

An exception to this policy is that TLS Server certificates issued through two subordinate Certificate Authorities managed by Apple, and identified below, will continue to be trusted as long as they are issued on or before December 31, 2019.

The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below.

An application will receive an Exception with a message indicating the trust anchor is not trusted, ex:

"TLS Server certificate issued after 2019-04-16 and anchored by a distrusted legacy Symantec root CA: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US"

If necessary, and at your own risk, you can work around the restrictions by removing "SYMANTEC_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Symantec Root certificates included in the JDK:

If you have a TLS Server certificate issued by one of the CAs above, you should have received a message from DigiCert with information about replacing that certificate, free of charge.

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server if not yours.

Command-Line Flag -XX:+ExtensiveErrorReports

The command-line flag -XX:+ExtensiveErrorReports has been added to allow more extensive reporting of information related to a crash as reported in the hs_err<pid>.log file. Disabled by default in product builds, the flag can be turned on in environments where maximal information is desired - even if the resulting logs may be quite large and/or contain information that might be considered sensitive.

HotSpot Windows OS Detection Correctly Identifies Windows Server 2019

Prior to this fix, Windows Server 2019 was recognized as "Windows Server 2016", which produced incorrect values in the os.name system property and the hs_err_pid file.

Epsilon GC Caused Excess Metaspace Resizing Safepoints

In this release, Epsilon has been changed to accept GC requests and resize the metaspace to reduce the number of safepoints that are taken.

Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload (for example, a workload having lots of classes) needed to resize the metaspace, it relied on the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be generated, but it would not resize the metaspace. This would cause another safepoint to be generated soon afterwards without ever resizing the metaspace.

Epsilon GC handled checked array stores incorrectly

Epsilon GC may have violated the specification requirements by accepting the type-incompatible store into the array, instead of throwing the ArrayStoreException. This is now handled correctly, both in this release, and associated backports. Users are advised to upgrade as soon as possible.

Support New Japanese Era in java.time.chrono.JapaneseEra

The JapaneseEra class and its of(int), valueOf(String), and values() methods are clarified to accommodate future Japanese era additions, such as how the singleton instances are defined, what the associated integer era values are, etc.