8u102 Update Release Notes

July 19, 2016

Java™ SE Development Kit 8, Update 102 (JDK 8u102)

The full version string for this update release is 1.8.0_102-b14 (where "b" means "build"). The version number is 8u102.

IANA Data 2016d

JDK 8u102 contains IANA time zone data version 2016d. For more information, refer to Timezone Data Versions in the JRE Software.
See JDK-8151876

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
8 1.8.0_101-b13
7 1.7.0_111-b13
6 1.6.0_121-b09


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 8u102) will expire with the release of the next critical patch update scheduled for October 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u102) on November 19, 2016. 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.


MSI Enterprise JRE Installer option, REMOVEOLDERJRES

MSI Enterprise JRE Installer option, REMOVEOLDERJRES, does not remove static installs.
JDK-8161098 (not public)



Support SHA224withDSA and SHA256withDSA in the SunJSSE provider
The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions.
See JDK-8049321


Internal package sun.invoke.anon has been removed
The internal package sun.invoke.anon has been removed. The functionality it used to provide, namely anonymous class loading with possible constant pool patches, is available via the Unsafe.defineAnonymousClass() method.
See JDK-8081512


New property jdk.lang.processReaperUseDefaultStackSize
When a large TLS (Thread local storage) size is set for Threads, the JVM results in a stack overflow exception. The reason for this behavior is that the reaper thread was created with a low stack size of 32768k. When a large TLS size is set, it steals space from the threads stack, which eventually results in a stack overflow. This is a known glibc bug.
To overcome this issue, we have introduced a workaround (jdk.lang.processReaperUseDefaultStackSize) in which the user can set the reaper threads stack size to a default instead of to 32768. This gives the reaper thread a bigger stack size, so for a large TLS size, such as 32k, the process will not fail.

Users can set this flag in one of two ways:
1. -Djdk.lang.processReaperUseDefaultStackSize=true
2. System.setProperty("jdk.lang.processReaperUseDefaultStackSize", "true")

The problem has been observed only when JVM is started from JNI code in which TLS is declared using "__thread"
See JDK-8130425

Implemented performance improvements for BigInteger.montgomeryMultiply
We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture.
See JDK-8130150

New Features

New system property for the remote JMX connector
*New JMX agent property - jmxremote.host*
A new property, com.sun.management.jmxremote.host, is introduced that specifies the bind address for the default JMX agent. If the latter is not specified, the default JMX agent will listen on all interfaces ( and the host value placed in the agent service URL (JMXServiceURL) is the IP address returned from invocation of the InetAddress.getLocalHost() method.

  • Name: com.sun.management.jmxremote.host
  • Definition: Specifies bind address for default JMX agent. It can be specified via command line while starting JVM or as part of agent config file (management.properties).
  • Value: IP address of any network interface of the machine
See JDK-6425769


Fixed memory leak when Java objects are passed into JavaScript
The bug fix for JDK-8089861, which was first integrated in JDK 8u102, fixes a memory leak when Java objects are passed into JavaScript. Prior to JDK 8u102, the WebView JavaScript runtime held a strong reference to such bound objects, which prevented them from being garbage collected. After the fix for JDK-8089861, the WebView JavaScript runtime uses weak references to refer to bound Java objects. The specification was updated to make it clear that this is the intended behavior.

Applications which rely on the previously unspecified behavior might be affected by the updated behavior if the application does not hold a strong reference to an object passed to JavaScript. In such case, the Java object might be garbage collected prematurely. The solution is to modify the application to hold a strong reference in Java code for objects that should remain live after being passed into JavaScript.
See JDK-8089681

Modify requirements on Authority Key Identifier extension field during X509 certificate chain building
The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases.
See JDK-8072463

Providing more granular levels for GC verification
This enhancement provides a way to specify more granular levels for the GC verification enabled using the VerifyBeforeGC, VerifyAfterGC, and VerifyDuringGC diagnostic options. It introduces a new diagnostic option VerifySubSet with which one can specify the subset of the memory system that should be verified.

With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap, and codecache_oops.

During the GC verification, only the sub-systems specified using VerifySubSet get verified:

D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test
[0.095s][debug ][gc,verify] Threads
[0.099s][debug ][gc,verify] C-heap
[0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms
[0.120s][debug ][gc,verify] Threads
[0.124s][debug ][gc,verify] C-heap
[0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms
[0.148s][debug ][gc,verify] Threads
[0.152s][debug ][gc,verify] C-heap

If any invalid memory sub-systems are specified with VerifySubSet, the Java process exits with the following error message:

D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom
Error occurred during initialization of VM
VerifySubSet: 'hello' memory sub-system is unknown, please correct it

See JDK-8072725

Removed PICL warning message
In 8u40 and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message:

Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing.
Performance will not be optimal.

This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed.
See JDK-8144957

Improved exception handling for bad LDAP referral replies
The JDK was throwing a NullPointerException when a non-compliant REFERRAL status result was sent but no referral values were included. With this change, a NamingException with message value of "Illegal encoding: referral is empty" will be thrown in such circumstances.
See JDK-8149450 and JDK-8154304

Bug Fixes

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

Fix to resolve "Unable to process PreMasterSecret, may be too big" issue
Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following :

handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big

See JDK-8149017

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