JDK 8u151 Release Notes

Java™ SE Development Kit 8, Update 151 (JDK 8u151)

October 17, 2017

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

IANA Data 2017b

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

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_151-b12
7 1.7.0_161-b13
6 1.6.0_171-b13

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 Third Party Bulletin. This JRE (version 8u151) will expire with the release of the next critical patch update scheduled for January 16, 2018.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u151) on February 16, 2018. 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 JRE Expiration Date.

Known Issues


Decode error with Tomcat version 7.x

The zlib version shipped in the 8u151 and 7u161 JDK releases was updated to zlib v1.2.11. The deflate functionality in this version causes a compatibility issue with Tomcat v7.x. Server responses can appear as corrupt or can fail to be decoded. The issue is seen if Tomcat is using compression (e.g. compression="on" in server.xml). This issue is being fixed via JDK-8189789.

Users can disable the compression mode on their Tomcat servers as a workaround. Tomcat versions 8.x and later don't appear to be affected.

See JDK-8191040



Better keystore handling

Due to the more rigorous procedure of reading a keystore content, some keystores (particularly, those created with old versions of the JDK or with a JDK from other vendors) might need to be regenerated.

The following procedure can be used to import the keystore:

1. Before you start, create a backup of your keystore. For example, if your keystore file is /DIR/KEYSTORE, make a copy of it:


Download an older release of the JDK, prior CPU17_04, and install it in a separate location. For example: 6u161, 7u151, or 8u141. Suppose, that older JDK is installed in the directory /JDK8U141

2. Make sure that the keystore can be successfully read with the keytool from that older directory. For example, if the keystore file is located in /DIR/KEYSTORE, the following command should successfully list its content:

/JDK8U141/bin/keytool -list /DIR/KEYSTORE

3. Import the keystore. For example:

            /JDK8U141/bin/keytool -importkeystore \
-srckeystore /DIR/KEYSTORE \
-srcstoretype JCEKS \
-srcstorepass PASSWORD \
-destkeystore /DIR/KEYSTORE.NEW \
-deststoretype JCEKS \
-deststorepass PASSWORD 


4. Verify that the newly created keystore is correct. At the very least, make sure that the keystore can be read with keytool from a newer JDK:

/NEW_JDK/bin/keytool -list /DIR/KEYSTORE.NEW

After successful verification, replace the old keystore with the new one:


Keep the backup copy of the keystore at least until you are sure the imported keystore is correct.

JDK-8181370 (not public)


Default timeouts have changed for FTP URL handler

Timeouts used by the FTP URL protocol handler have been changed from infinite to 5 minutes. This will result in an IOException from connect and read operations if the FTP server is unresponsive. For example, new URL("").openStream().read(), will fail with in case a connection or reading could not be completed within 5 minutes.

To revert this behaviour to that of previous releases, the following system properties may be used,,

JDK-8181612 (not public)


Demo references in Solaris install documentation

Demos were removed from package tar.Z bundle(JDK-7066713). There is a separate Demos&Samples bundle beginning with 7u2 b08 and 6u32 b04, but Solaris patches still contain SUNWj7dmo/SUNWj6dmo. The 64 bit packages are SUNWj7dmx/SUNWj6dmx

Demo packages remain in the existing Solaris patches; however, just because they are there doesn't mean that they are installed. They will be patched only if the end user has them installed on the system.

The link above is to the Solaris OS Install Directions for the JDK. The SUNWj7dmx package is mentioned in the tar.Z portion of the directions. This is confusing to some as, according to the cited bug, the SUNWj7dmx package shouldn't be part of the tar.Z bundle.

See JDK-8175866

Certificate Changes

Remove revoked Swisscom root certificate "swisscomrootevca2"

One Swisscom root certificate has been revoked by Swisscom and has been removed:

        Swisscom Root EV CA 2
alias: "swisscomrootevca2 [jdk]"
DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch

JDK-8186330 (not public)

New Features


New Security property to control crypto policy

This release introduces a new feature whereby the JCE jurisdiction policy files used by the JDK can be controlled via a new Security property. In older releases, JCE jurisdiction files had to be downloaded and installed separately to allow unlimited cryptography to be used by the JDK. The download and install steps are no longer necessary. To enable unlimited cryptography, one can use the new crypto.policy Security property. If the new Security property (crypto.policy) is set in the file, or has been set dynamically by using the Security.setProperty() call before the JCE framework has been initialized, that setting will be honored. By default, the property will be undefined. If the property is undefined and the legacy JCE jurisdiction files don't exist in the legacy lib/security directory, then the default cryptographic level will remain at 'limited'. To configure the JDK to use unlimited cryptography, set the crypto.policy to a value of 'unlimited'. See the notes in the file shipping with this release for more information.

Note: On Solaris, it's recommended that you remove the old SVR4 packages before installing the new JDK updates. If an SVR4 based upgrade (without uninstalling the old packages) is being done on a JDK release earlier than 6u131, 7u121, 8u111, then you should set the new crypto.policy Security property in the file.

Because the old JCE jurisdiction files are left in <java-home>/lib/security, they may not meet the latest security JAR signing standards, which were refreshed in 6u131, 7u121, 8u111, and later updates. An exception similar to the following might be seen if the old files are used:

Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies( at javax.crypto.JceSecurity.setupJurisdictionPolicies(

See JDK-8157561

 Add Additional IDL Stub Type Checks to org.omg.CORBA.ORB::string_to_object Method

Applications that either explicitly or implicitly call org.omg.CORBA.ORB.string_to_object, and wish to ensure the integrity of the IDL stub type involved in the ORB::string_to_object call flow, should specify additional IDL stub type checking. This is an "opt in" feature and is not enabled by default.

To take advantage of the additional type checking, the list of valid IDL interface class names of IDL stub classes is configured by one of the following:

  • Specifying the security property com.sun.CORBA.ORBIorTypeCheckRegistryFilter located in the file conf/security/ in Java SE 9 or in jre/lib/security/ in Java SE 8 and earlier.

  • Specifying the system property com.sun.CORBA.ORBIorTypeCheckRegistryFilter with the list of classes. If the system property is set, its value overrides the corresponding property defined in the configuration.

If the com.sun.CORBA.ORBIorTypeCheckRegistryFilter property is not set, the type checking is only performed against a set of class names of the IDL interface types corresponding to the built-in IDL stub classes.

JDK-8160104 (not public)



Refactor existing providers to refer to the same constants for default values for key length

Two important changes have been made for this issue:

1. A new system property has been introduced that allows users to configure the default key size used by the JDK provider implementations of KeyPairGenerator and AlgorithmParameterGenerator. This property is named "" and the value of this property is a list of comma-separated entries. Each entry consists of a case-insensitive algorithm name and the corresponding default key size (in decimal) separated by ":". In addition, white space is ignored.

By default, this property will not have a value, and JDK providers will use their own default values. Entries containing an unrecognized algorithm name will be ignored. If the specified default key size is not a parseable decimal integer, that entry will be ignored as well.

2. The DSA KeyPairGenerator implementation of the SUN provider no longer implements Applications which cast the SUN provider's DSA KeyPairGenerator object to a can set the system property "". If the value of this property is "true", the SUN provider will return a DSA KeyPairGenerator object which implements the interface. This legacy implementation will use the same default value as specified by the javadoc in the interface.

By default, this property will not have a value, and the SUN provider will return a DSA KeyPairGenerator object which does not implement the forementioned interface and thus can determine its own provider-specific default value as stated in the class or by the "" system property if set.

JDK-8181048 (not public)


Collections use serialization filter to limit array sizes

Deserialization of certain collection instances will cause arrays to be allocated. The ObjectInputFilter.checkInput() method is now called prior to allocation of these arrays. Deserializing instances of ArrayDeque, ArrayList, IdentityHashMap, PriorityQueue, java.util.concurrent.CopyOnWriteArrayList, and the immutable collections (as returned by List.of, Set.of, and Map.of) will call checkInput() with a FilterInfo instance whose style="font-family: Courier New;">serialClass() method returns Object[].class. Deserializing instances of HashMap, HashSet, Hashtable, and Properties will call checkInput() with a FilterInfo instance whose serialClass() method returns Map.Entry[].class. In both cases, the FilterInfo.arrayLength() method will return the actual length of the array to be allocated. The exact circumstances under which the serialization filter is called, and with what information, is subject to change in future releases.

JDK-8174109 (not public)


keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms

With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing TrustedCertificateEntry, either in the keystore directly operated on or in the cacerts keystore when the -trustcacerts option is specified for the -importcert command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file cert contains a CA certificate signed with a weak signature algorithm, keytool -printcert -file cert and keytool -importcert -file cert -alias ca -keystore ks will print out a warning, but after the last command imports it into the keystore, keytool -list -alias ca -keystore ks will not show a warning anymore.

Precisely, an algorithm or a key is weak if it matches the value of the jdk.certpath.disabledAlgorithms security property defined in the conf/security/ file.

See JDK-8171319


New defaults for DSA keys in jarsigner and keytool

For DSA keys, the default signature algorithm for keytool and jarsigner has changed from SHA1withDSA to SHA256withDSA and the default key size for keytool has changed from 1024 bits to 2048 bits.

Users wishing to revert to the previous behavior can use the -sigalg option of keytool and jarsigner and specify SHA1withDSA and the -keysize option of keytool and specify 1024.

There are a few potential compatibility risks associated with this change:

  1. If you have a script that uses the default key size of keytool to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:
                    keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
    keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...

    it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:

                    keytool error: The security strength of 
    SHA-1 digest algorithm is not sufficient for this key size
    keytool error: DSA key must be at most 
    1024 bits

    The workaround is to remove the -sigalg option and use the stronger SHA256withDSA default or, at your own risk, use the -keysize option of keytool to specify a smaller key size (1024).

  2. If you use jarsigner to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. jarsigner -verify on an earlier release of JDK 6 or 7 will output the following error:

    jar is unsigned. (signatures missing or not parsable)

    If you add to the jarsigner command line, the cause will be output:

                    jar: processEntry caught: 
    SHA256withDSA Signature not available

    If compatibility with earlier releases is important, you can, at your own risk, use the -sigalg option of jarsigner and specify the weaker SHA1withDSA algorithm.

  3. If you use a PKCS11 keystore, the SunPKCS11 provider does not support the SHA256withDSA algorithm. jarsigner and some keytool commands may fail with the following exception if PKCS11 is specified with the -storetype option, ex:
                    keytool error: No installed provider
    supports this key:$P11PrivateKey 

    A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the -sigalg option of keytool and specify SHA1withDSA.

See JDK-8057810


Add warnings to keytool when using JKS and JCEKS

When keytool is operating on a JKS or JCEKS keystore, a warning may be shown that the keystore uses a proprietary format and migrating to PKCS12 is recommended. The keytool's -importkeystore command is also updated so that it can convert a keystore from one type to another if the source and destination point to the same file.

JDK-8182879 (not public)


keytool now prints out information of a certificate's public key

Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: <size>-bit RSA key", where <size> is the key size in bits (ex: 2048).

See JDK-8029659


Improve javadoc generation

The Javadoc Standard Doclet documentation has been enhanced to specify that it doesn't validate the content of documentation comments for conformance, nor does it attempt to correct any errors in documentation comments. See the Conformance section in the Doclet documentation.

JDK-8179042 (not public)


Bug Fixes

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

# BugId Component Subcomponent Summary
1 JDK-8179084 hotspot gc HotSpot VM fails to start when AggressiveHeap is set
2 JDK-8089283 javafx web Padding property of the select tag is incorrect in WebView
3 JDK-8132675 javafx web VBox.setVgrow and HBox.setHgrow corrupt following controls when window resized
4 JDK-8138652 javafx web [macosx] New WebView Native Code uses private Apple APIs
5 JDK-8165909 javafx web JavaScript to Java String conversion is not correct
6 JDK-8170450 javafx web Crash while loading in HiDPI / Retina display
7 JDK-8172495 javafx web Ignore __cmake_systeminformation from web module build directory
8 JDK-8172836 javafx web WebView Debug build is broken
9 JDK-8176729 javafx web com.sun.webkit.dom.NodeImpl#SelfDisposer is not called
10 JDK-8178319 javafx web Build sqlite3 from source
11 JDK-8178360 javafx web Build and integrate ICU from source
12 JDK-8178440 javafx web Build libxml2 and libxslt from source
13 JDK-8179673 javafx web JVM Crash in WebPage.setBackgroundColor() during webpage navigation (Non Public API)
14 JDK-8180825 javafx web Javafx WebView fails to render pdf.js
15 JDK-8183292 javafx web Update to 604.1 version of WebKit
16 JDK-8184448 javafx web Crash while loading gif images with more frames
17 JDK-8185132 javafx web window.requestAnimationFrame API is not working
18 JDK-8172847 javafx window‑toolkit [macos] If you hit the escape key repeatedly to close the subwindow, the process crashes
19 JDK-8029659 security‑libs Keytool, print key algorithm of certificate or key entry
20 JDK-8154015 security‑libs Apply algorithm constraints to timestamped code
21 JDK-8171319 security‑libs keytool should print out warnings when reading or generating cert/cert req using weak algorithms
22 JDK-8177569 security‑libs keytool should not warn if signature algorithm used in cacerts is weak
23 JDK-8157561 security‑libs javax.crypto Ship the unlimited policy files in JDK Updates
24 JDK-8167485 tools visualvm Integrate new version of Java VisualVM based on VisualVM 1.3.9 into JDK