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.
JDK 8u102 contains IANA time zone data version 2016d. For more information, refer to Timezone Data Versions in the JRE Software.
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
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
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:
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:+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
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).
IP address of any network interface of the machine
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
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:
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.
.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\myName\AppData\Roaming depending upon whether the user is local, or is a network user.
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
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.