July 19, 2016
The full version string for this update release is 1.8.0_102-b14 (where "b" means "build"). The version number is 8u102.
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)
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, 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.
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.
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:
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"
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.
32/64-bit interoperability in Java Web Start
The ability to specify a preference to launch a Java Web Start application in 64-bit or 32-bit architectures is now supported, by adding the 'arch' attribute to the JNLP resources block.
Ability to limit the capacity of buffers that can be held in the temporary buffer cache
The system property jdk.nio.maxCachedBufferSize has been introduced in 8u102 to limit the memory used by the "temporary buffer cache." The temporary buffer cache is a per-thread cache of direct memory used by the NIO implementation to support applications that do I/O with buffers backed by arrays in the java heap. The value of the property is the maximum capacity of a direct buffer that can be cached. If the property is not set, then no limit is put on the size of buffers that are cached. Applications with certain patterns of I/O usage may benefit from using this property. In particular, an application that does I/O with large multi-megabyte buffers at startup but does I/O with small buffers may see a benefit to using this property. Applications that do I/O using direct buffers will not see any benefit to using this system property.
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 (0.0.0.0) and the host value placed in the agent service URL (JMXServiceURL) is the IP address returned from invocation of the InetAddress.getLocalHost() method.
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.
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
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.
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
The following are some of the notable bug fixes included in this release:
.oracle_jre_usage folder is no longer created in C\Users\myName
Since JDK 1.8.0_60, a folder named .oracle_jre_usage is created in the home directory. This folder and the files inside it are created by the Java Runtime Environment to track the last time a JRE was used. This information is very important in understanding what JRE installations are currently being used on the system.
On Windows, this folder was created under either C:\Users\
Writing content in this folder over the network on Windows can introduce performance overhead. This problem has been fixed with JDK-8134300. With this fix, the .oracle_jre_usage folder is created under %ProgramData%/Oracle/Java/.
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
With UseG1GC, specifying -XX:ParallelGCThreads=0 is no longer allowed
With UseG1GC, specifying -XX:ParallelGCThreads=0 is no longer allowed. Previously, with -XX:ParallelGCThreads=0, G1 would execute some tasks using serial code executed by the VM thread. The closest approximation of this behavior is to specify -XX:ParallelGCThreads=1, which causes parallel tasks to be executed by a single GC worker thread using parallel code.
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.