RELEASE NOTES: JDK 8u102

Set 32 or 64 bit JRE requirements in a JNLP file

Web Start applications can now specify requested JREs with their arch attributes, and select the first one available that matches, even if it is not the same arch (32 bit vs 64 bit) as the currently running JRE. For example, the JNLP content below would place first preference on 64 bit JDK8, and if not available, 32 bit JDK9: ` <resources arch="x86_64"> <java version="1.8"/> </resources> <resources arch="x86"> <java version="1.9"/> </resources> ` Note that in the above example, in order to launch a 64 bit 1.8 JRE, a 64 bit 9 JRE must be installed. If only a 32 bit 9 JRE is installed, the 64 bit 1.8 JRE is unavailable.

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.

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.

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 for more details

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.

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 `

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.

.oracle_jre_usage folder no longer created in C:\Users\myName

Since JDK 1.8.060, a folder named .oraclejre_usage gets 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 gets created under either C:\Users\<username>\AppData\Local or 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 bug JDK-8134300. With this fix .oraclejreusage folder gets created under %ProgramData%/Oracle/Java/

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 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 if an application does I/O with large multi-megabyte buffers at startup but therefore 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 InetAddress.getLocalHost() method.

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

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"

Comodo Root CA removed

The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file.

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.

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.

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 using 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, symboltable, stringtable, codecache, dictionary, classloaderdatagraph, metaspace, jnihandles, c-heap and codecacheoops.

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, 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 ```