JDK 8u221 Update Release Notes



Java™ SE Development Kit 8, Update 221 (JDK 8u221)

July 16, 2019

The full version string for this update release is 1.8.0_221-b11 (where "b" means "build"). The version number is 8u221.

IANA Data 2018i

JDK 8u221 contains IANA time zone data version 2018i. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u221 are specified in the following table:

JRE Family Version JRE Security Baseline
(Full Version String)
8 1.8.0_221-b11
7 1.7.0_231-b08

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. This JRE (version 8u221) will expire with the release of the next critical patch update scheduled for October 15, 2019.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u221) on November 15, 2019. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

New Features

hotspot/runtime
 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.

 

Removed Features and Options

security-libs/java.security
 Removal of Two DocuSign Root CA Certificates 

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

 

security-libs/java.security
 Removal of Two Comodo Root CA Certificates 

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

 

security-libs/java.security
 Removal of T-Systems Deutsche Telekom Root CA 2 Certificate 

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

Other notes

install
 Java Access Bridge Installation Workaround

There is a risk of breaking Java Access Bridge functionality when installing Java on a Windows system that has both a previously installed version of Java and an instance of JAWS running. After rebooting, the system can be left without the WindowsAccessBridge-64.dll in either the system directory (C:\Windows\System32) for 64bit Java products or the system directory used by WOW64 (C:\Windows\SysWoW64) for 32bit Java products.

To prevent breaking Java Access Bridge functionality, use one of the following workarounds:

  • Stop JAWS before running the Java installer.
  • Uninstall the existing JRE(s) before installing the new version of Java.
  • Uninstall the existing JRE(s) after the new version of Java is installed and the machine is rebooted.

The goal of the workarounds is to avoid the scenario of uninstalling existing JRE(s) from Java installer when JAWS is running.

JDK-8223293 (not public)

 

security-libs/javax.crypto
 System Property to Switch Between Implementations of ECC

A new boolean system property, jdk.security.useLegacyECC, has been introduced that enables switching between implementations of ECC.

When the system property, jdk.security.useLegacyECC, is set to "true" (the value is case-insensitive) the JDK uses the old, native implementation of ECC. If the option is set to an empty string, it is treated as if it were set to "true". This makes it possible to specify -Djdk.security.useLegacyECC in the command line.

If the option is explicitly set to "false", the provider decides which implementation of ECC is used.

The default value of the option is "true". Note that the default value might change in a future update release of the JDK.

JDK-8217763 (not public)

 

client-libs/2d
 Missing Glyphs in AWT/Swing Components Due to Lack of CJK TrueType Fonts in RHEL 8

Red Hat Enterprise Linux 8 no longer includes packages which provided TrueType fonts used by JDK for CJK (Chinese, Japanese, and Korean) languages.

Text display for those languages will therefore result in missing glyphs.

See JDK-8209672 for a resolution to this issue.

 


Bug Fixes 

This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 8u221 Bug Fixes page.