Log Message:
Update to 1.8.102

Changelog:
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

Enhancements

core-libs/java.lang.invoke
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

hotspot/runtime
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

hotspot/compiler
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

Changes
security-libs/javax.crypto
MSCAPI KeyStore can handle same-named certificates
Java SE KeyStore does not allow certificates that have the same
aliases
(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html).
However, on Windows, multiple certificates stored in one keystore
are allowed to have non-unique friendly names.The fix for JDK-6483657
makes it possible to operate on such non-uniquely named certificates
through the Java API by artificially making the visible aliases
unique.

Please note, this fix does not enable creating same-named certificates
with the Java API. It only allows you to deal with same-named
certificates that were added to the keystore by 3rd party tools.

It is still recommended that your design not use multiple certificates
with the same name. In particular, the following sentence will not
be removed from the Java documentation:  "In order to avoid problems,
it is recommended not to use aliases in a KeyStore that only differ
in case."
(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html)
See JDK-6483657

security-libs/javax.net.ssl
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

hotspot/gc
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

hotspot/compiler
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

core-libs/javax.naming
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:

security-libs/javax.net.ssl
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.