Java SE 8u152 Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u152 BPRs. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u152 b35

Bug Fixes

Changes in Java SE 8u152 b34

Bug Fixes

Changes in Java SE 8u152 b33

Bug Fixes

Changes in Java SE 8u152 b32

Bug Fixes

Changes in Java SE 8u152 b31

Please note that fixes from prior BPR (8u144 b34) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 152 (JDK 8u152)

October 17, 2017

The full version string for this update release is 1.8.0_152-b16 (where "b" means "build"). The version number is 8u152.

IANA Data 2017b

JDK 8u152 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

See JDK-8159684

Security Baselines

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

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 8u152) 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 8u152) 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

core-libs/java.util.jar

 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

New Features

security-libs/javax.crypto

 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 java.security file, or has been set dynamically 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 java.security 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, or 8u111, then you should set the new crypto.policy Security property in the java.security 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(JceSecurity.java:593) 
       at 
javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)

See JDK-8157561

Changes

hotspot/compiler

 BigInteger performance improvements turned on by default

The performance improvements described in JDK-8130150 and JDK-8081778 have now been turned on by default. They can be turned off by using the following command options:

-XX:-UseMontgomerySquareIntrinsic
-XX:-UseMontgomeryMultiplyIntrinsic
-XX:-UseSquareToLenIntrinsic 
-XX:-UseMultiplyToLenIntrinsic 

See JDK-8154945

Bug Fixes

The following are some of the notable bug fixes included in this release:

hotspot/compiler

 Compilers accept modification of final fields outside initializer methods

According to the Java VM Specification, final fields can be modified by the putfield byte code instruction only if the instruction appears in the instance initializer method <init> of the field's declaring class. Similar, static final fields can be modified by a putstatic instruction only if the instruction appears in the class initializer method <clinit> of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53 final fields can be modified in any method of the class declaring the field (not only class/instance initializers).

See JDK-8157181

Bug Fix List

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