RELEASE NOTES: JDK 8u152

JNLP files won't launch from IE11 on Windows 10 Creators Update

Web-start applications cannot be launched when clicking JNLP link from IE 11 on Windows 10 Creators Update when 64-bit JRE is installed. Workaround is to uninstall 64-bit JRE and use only 32-bit JRE.

JNLP files won't launch from IE11 on Windows 10 Creators Update

Web-start applications cannot be launched when clicking JNLP link from IE 11 on Windows 10 Creators Update when 64-bit JRE is installed. Workaround is to uninstall 64-bit JRE and use only 32-bit JRE.

Change to Internal Java Package Names in RPM Installers

On the Linux platform, the names of JRE and JDK packages provided by Java RPM installers have been changed. Names of JRE and JDK packages follow jre<major.minor> and jdk<major.minor> patterns respectively instead of the jre and jdk previously used. For example, the new names of JRE and JDK packages are jre1.8 and jdk1.8 respectively.

On Linux platform, the names of installation directories of Java products have also been changed. The installation directories of products from the 8u171 release are as follows: /usr/java/jre1.8.0_171-i586 for 32bit JRE /usr/java/jdk1.8.0_171-i586 for 32bit JDK /usr/java/jre1.8.0_171-amd64 for 64bit JRE /usr/java/jdk1.8.0_171-amd64 for 64bit JDK

Change to Internal Java Package Names in RPM Installers

On the Linux platform, the names of JRE and JDK packages provided by Java RPM installers have been changed. The names of JRE and JDK packages now follow jre<major.minor> and jdk<major.minor> patterns respectively, instead of jre and jdk previously used. For example, the new names of JRE and JDK packages are jre1.7 and jdk1.7 respectively.

On the Linux platform, the names of installation directories of Java products have also been changed. The installation directories of products from the 7u181 release are as follows: /usr/java/jre1.7.0_181-i586 for 32bit JRE /usr/java/jdk1.7.0_181-i586 for 32bit JDK /usr/java/jre1.7.0_181-amd64 for 64bit JRE /usr/java/jdk1.7.0_181-amd64 for 64bit JDK

Add mechanism to allow non default root CAs to not be subject to algorithm restrictions

'New certpath constraint: jdkCA In the java.security file, an additional constraint named "jdkCA" is added to the jdk.certpath.disabledAlgorithms property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression.

Example:  To apply this constraint to SHA-1 certificates, include the following:  `SHA1 jdkCA`

RMI Registry Filter Allows Binding Arrays of Any Type

The RMI Registry built-in serial filter has been modified to check only the array size and not the component type. The maximum array size has been increased to 1,000,000. The override filter can be used to decrease the limit. Array sizes greater than the maxarray limit will be rejected. Sizes less than the maxarray limit will be allowed.

The java.security file contains more information about the sun.rmi.registry.registryFilter property and the conf/security/java.security configuration file has been updated to better describe the default behavior and how to override it.

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).

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 `

Improve the default strength of EC in JDK.

To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192").

EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example:

jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"

Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties.

IllegalArgumentException from TLS handshake

A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code.

`java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves`

The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.

See JDK-8173783