We’re sorry. We could not find a match for your search.

We suggest you try the following to help find what you’re looking for:

  • Check the spelling of your keyword search.
  • Use synonyms for the keyword you typed, for example, try "application" instead of "software."
  • Start a new search.
Cloud Account Sign in to Cloud
Oracle Account

7u111 Update Release Notes

July 19, 2016

Update Release Notes Index

Java™ SE Development Kit 7, Update 111 (JDK 7u111)

The full version string for this update release is 1.7.0_111-b13 (where "b" means "build"). The version number is 7u111.

IANA Data 2016d

JDK 7u111 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 7u111 are specified in the following table:

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u111) 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 7u111) 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.

Certificate Changes

New DTrust certificates added to root CAs
Two new root certificates have been added:

D-TRUST Root Class 3 CA 2 2009
alias: dtrustclass3ca2
DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE

D-TRUST Root Class 3 CA 2 EV 2009
alias: dtrustclass3ca2ev
DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
See JDK-8153080

New IdenTrust certificates added to root CAs
Three new root certificates have been added:

IdenTrust Public Sector Root CA 1
alias: identrustpublicca
DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US

IdenTrust Commercial Root CA 1
alias: identrustcommercial
DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US

IdenTrust DST Root CA X3
alias: identrustdstx3
DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
See JDK-8154757

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

Sonera Class1 CA removed
The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file.
See JDK-8141276



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 the 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


os.name support for Windows 10

JDK 7u111 now prints Windows 10 for os.name System property queries running on Windows 10 systems.

See JDK-8149143



Improve access control to javax.rmi.CORBA.ValueHandler

The javax.rmi.CORBA.Util class provides methods that can be used by stubs and ties to perform common operations. It also acts as a factory for ValueHandlers. The javax.rmi.CORBA.ValueHandler interface provides services to support the reading and writing of value types to GIOP streams. The security awareness of these utilities has been enhanced with the introduction of a permission java.io.SerializablePermission("enableCustomValueHanlder"). This is used to establish a trust relationship between the users of the javax.rmi.CORBA.Util and javax.rmi.CORBA.ValueHandler APIs.

The required permission is "enableCustomValueHanlder" SerializablePermission. Third party code running with a SecurityManager installed, but not having the new permission while invoking Util.createValueHandler(), will fail with an AccessControlException.

This permission check behaviour can be overridden, in JDK8u and previous releases, by defining a system property, "jdk.rmi.CORBA.allowCustomValueHandler".

As such, external applications that explicitly call javax.rmi.CORBA.Util.createValueHandler require a configuration change to function when a SecurityManager is installed and neither of the following two requirements is met:

  1. The java.io.SerializablePermission("enableCustomValueHanlder") is not granted by SecurityManager.
  2. In the case of applications running on JDK8u and before, the system property "jdk.rmi.CORBA.allowCustomValueHandler" is either not defined or is defined equal to "false" (case insensitive).

Please note that the "enableCustomValueHanlder" typo will be corrected in the October 2016 releases. In those and future JDK releases, "enableCustomValueHandler" will be the correct SerializationPermission to use.

JDK-8079718 (not public)


Support added to jarsigner for specifying timestamp hash algorithm

A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream.

See JDK-8038837


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


DomainCombiner will no longer consult runtime policy for static ProtectionDomain objects when combining ProtectionDomain objects

Applications which use static ProtectionDomain objects (created using the 2-arg constructor) with an insufficient set of permissions may now get an AccessControlException with this fix. They should either replace the static ProtectionDomain objects with dynamic ones (using the 4-arg constructor) whose permission set will be expanded by the current Policy or construct the static ProtectionDomain object with all the necessary permissions.

JDK-8147771 (not public)

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 7u111 Bug Fixes page.