JDK 8u211 Release Notes

Java™ SE Development Kit 8, Update 211 (JDK 8u211)

April 16, 2019

The full version string for this update release is 1.8.0_211-b12 (where "b" means "build"). The version number is 8u211.

IANA Data 2018g

JDK 8u211 contains IANA time zone data version 2018g. 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 8u211 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_211-b12
7 1.7.0_221-b08
6 1.6.0_221

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 8u211) will expire with the release of the next critical patch update scheduled for July 16, 2019.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u211) on August 16, 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


 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.

See JDK-8205432


 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

See JDK-8211398


 High DPI Auto-Scaling on Windows

If the Windows desktop DPI of the default screen is configured via Display Settings to be 150% or greater (that is 144 dpi or greater), JDK will now ask Windows to auto-scale the entire UI of a Java application to be consistent with the rest of the Windows desktop UI.

Below that value Java applications will appear at the same size as they did in previous releases.

This threshold is chosen as a trade-off between compatibility and legibility of the UI. At higher DPI settings, without this auto-scaling, the Java UI may be just too small to be read comfortably.

There may be some negative consequences such as

  • Some elements of the UI may appear somewhat blurry, particularly if the scaling factor is a non-integral value (that is 1.5 rather than 2.0).
  • ClearType text is not effective when auto-scaling so grey scale anti-aliasing is used instead by the Swing toolkit.
  • Window sizing and positioning calculations may be adversely affected.

In the event that the negative consequences outweigh the benefits, an application can request the old behaviour by specifying:


Conversely, if the application would prefer to be auto-scaled even at lower DPI settings, then specify:


In the absence of either explicit setting, the default behaviour described above will apply.

JDK-8204512 (not public)


 New Currency Code Points Added

The Java SE 8 Platform spec for java.lang.Character now supports Unicode 6.2 plus an extension to allow new currency code points from Unicode 10.0.

The following currency code points have been added:


See JDK-8217710

Known Issues


 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)


 Possible Performance Regression in JDK 8 Updates 202, 211, and 212

Due to a known issue with the fix for JDK-8155635, introduced in JDK 8 update 202, some applications may experience a performance regression (lower throughput and/or higher CPU consumption) when migrating from earlier releases. Examples of code that might trigger this regression include heavy use of sun.misc.Unsafe and the Reflection API. This performance regression is addressed in JDK-8221355.

See JDK-8221355



 Added GlobalSign R6 Root Certificate 

The following root certificate has been added to the cacerts truststore:

  • GlobalSign
    • globalsignrootcar6

      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6

JDK-8216577 (not public)


 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 security property in the configuration file.

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

Root Certificates distrusted after 2019-04-16

Distinguished Name SHA-256 Fingerprint
CN=GeoTrust Global CA, O=GeoTrust Inc., C=US

FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA: DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A

CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US

37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8: 2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C

CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US

5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F: 7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66

CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US

B4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E: E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4

CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US

A0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93: 42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12

CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US

8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A: 97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F

CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US

A4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB: 43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57

CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US

4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C: 06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47: 9C:36:93:65:08:80:50:56:98:10:5D:BC:E9

OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F: D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1

OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09: CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05

OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E: DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B

CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

EB:04:CF:5E:B1:F3:9A:FA:76:2F:2B:B1:20:F2:96:CB:A5:20:C1: B9:7D:B1:58:95:65:B8:1C:B9:A1:7B:72:44

CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

69:DD:D7:EA:90:BB:57:C9:3E:13:5D:C8:5E:A6:FC:D5:48:0B:60: 32:39:BD:C4:54:FC:75:8B:2A:26:CF:7F:79

CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

9A:CF:AB:7E:43:C8:D8:80:D0:6B:26:2A:94:DE:EE:E4:B4:65:99: 89:C3:D0:CA:F1:9B:AF:64:05:E4:1A:B7:DF

CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5: C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C

Subordinate Certificates distrusted after 2019-12-31

Distinguished Name SHA-256 Fingerprint
CN=Apple IST CA 2 - G1, OU=Certification Authority, O=Apple Inc., C=US

AC:2B:92:2E:CF:D5:E0:17:11:77:2F:EA:8E:D3:72:DE:9D:1E:22:45:FC:E3:F5:7A: 9C:DB:EC:77:29:6A:42:4B

CN=Apple IST CA 8 - G1, OU=Certification Authority, O=Apple Inc., C=US

A4:FE:7C:7F:15:15:5F:3F:0A:EF:7A:AA:83:CF:6E:06:DE:B9:7C:A3:F9:09:DF:92:0A: C1:49:08:82:D4:88:ED

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.

See JDK-8207258


 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.

See JDK-8212941

Bug Fixes 

This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update.

# BugId Component Subcomponent Summary
1 JDK-8213983 client-libs java.awt [macosx] Keyboard shortcut ???cmd +`??? stops working properly if popup window is displayed
2 JDK-8213583 client-libs java.awt Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files
3 JDK-8076164 client-libs javax.swing [JTextField] When input too long Thai character, cursor's behavior is odd
4 JDK-8132136 client-libs javax.swing [PIT] RTL orientation in JEditorPane is broken
5 JDK-8133108 client-libs javax.swing [PIT] Container size is wrong in JEditorPane
6 JDK-8187364 client-libs javax.swing Unable to enter zero width non-joiner (ZWNJ) symbol in Swing text component
7 JDK-8216396 core-libs java.lang Support new Japanese era and new currency code points in java.lang.Character for Java SE 8
8 JDK-8218915 core-libs java.lang Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
9 JDK-8217710 core-libs java.lang Add 5 currency code points to Java SE 8uX
10 JDK-8180469 core-libs java.time Wrong short form text for supplemental Japanese era
11 JDK-8212941 core-libs java.time Support new Japanese era in java.time.chrono.JapaneseEra
12 JDK-8211398 core-libs java.util:i18n Square character support for the Japanese new era
13 JDK-8202088 core-libs java.util:i18n Japanese new era implementation
14 JDK-8207152 core-libs java.util:i18n Placeholder for Japanese new era should be two characters
15 JDK-8217609 core-libs java.util:i18n New era placeholder not recognized by java.text.SimpleDateFormat
16 JDK-8159886 deploy plugin Window of a newly launched Oracle Forms applet loses focus
17 JDK-8133984 hotspot runtime print_compressed_class_space() is only defined in 64-bit VM
18 JDK-8180904 hotspot test Hotspot tests running with -agentvm failing due to classpath
19 JDK-8187220 install install postinstall fails if there is a space in user name
20 JDK-8214185 javafx media Upgrade GStreamer to the latest (1.14.4) version
21 JDK-8200665 javafx samples Ensemble: Update SyntaxHighlighter to version 4.0.1
22 JDK-8207772 javafx web File API and FileReader should be supported in WebView
23 JDK-8213541 javafx web WebView does not handle HTTP response without ContentType
24 JDK-8215702 javafx web SVG gradients are not rendered
25 JDK-8215799 javafx web Complex text is not rendered by webkit on Windows
26 JDK-8214119 javafx web Update to 607.1 version of WebKit
27 JDK-8211399 javafx web libxslt fails to build with glibc 2.26
28 JDK-8211454 javafx web Update SQLite to version 3.26.0
29 JDK-8214452 javafx web Update libxml2 to version 2.9.9
30 JDK-8213806 javafx web WebView - JVM crashes for given HTML
31 JDK-8218611 javafx web [DRT] fast/xslt tests fails with Unsupported encoding windows-1251
32 JDK-8219539 javafx web Cherry pick GTK WebKit 2.22.6 changes
33 JDK-8133802 security-libs   replace some <tt> tags (obsolete in html5) in security-libs docs
34 JDK-8216280 security-libs Allow later Symantec Policy distrust date for two Apple SubCAs
35 JDK-8215318 security-libs Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions
36 JDK-8029661 security-libs Support TLS v1.2 algorithm in SunPKCS11 provider
37 JDK-8207258 security-libs Distrust TLS server certificates anchored by Symantec Root CAs
38 JDK-8129988 security-libs JSSE should create a single instance of the cacerts KeyStore
39 JDK-8217579 security-libs TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883
40 JDK-8203190 security-libs SessionId.hashCode generates too many collisions
41 JDK-8164656 security-libs org.ietf.jgss:krb5 krb5 does not retry if TCP connection timeouts