Java 8 release changes

Java 8 Release Highlights

This article applies to:

Java version(s): 8.0

This page highlights changes impacting end users for each Java release. More information about changes can be found in the release notes for each release.
» Java release dates

Java 8 Update 191 (8u191)

Release Highlights

IANA Data 2018e
JDK 8u191 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.
Change: Changed Central File System Location for usagetracker.properties File
The file system location in Windows for the usagetracker.properties file has been moved from %ProgramData%\Oracle\Java\ to %ProgramFiles%\Java\conf
There is no change in the file path for Linux, Solaris, or macOS. JDK-8204901 (not public)
Change: Disabled all DES TLS Cipher Suites
DES-based TLS cipher suites are considered obsolete and should no longer be used. DES-based cipher suites have been deactivated by default in the SunJSSE implementation by adding the "DES" identifier to the jdk.tls.disabledAlgorithms security property. These cipher suites can be reactivated by removing "DES" from the jdk.tls.disabledAlgorithms security property in the java.security file or by dynamically calling the Security.setProperty() method. In both cases re-enabling DES must be followed by adding DES-based cipher suites to the enabled cipher suite list using the SSLSocket.setEnabledCipherSuites() or SSLEngine.setEnabledCipherSuites() methods.
Note that prior to this change, DES40_CBC (but not all DES) suites were disabled via the jdk.tls.disabledAlgorithms security property.
See JDK-8208350
Change: Removal of Several Symantec Root CAs
The following Symantec root certificates are no longer in use and have been removed:
- Symantec
  - equifaxsecureca
    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  - equifaxsecureglobalebusinessca1
    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
  - equifaxsecureebusinessca1
    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
  - verisignclass1g3ca
    DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass2g3ca
    DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass1g2ca
    DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  - verisignclass1ca
    DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
See JDK-8191031
Change: Removal of Baltimore Cybertrust Code Signing CA
The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed:
- baltimorecodesigningca
  DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
See JDK-8189949
Bug Fix: LDAPS Communication Failure
Application code using LDAPS with a socket connect timeout that is <= 0 ( the default value ), running on the July CPU 2018 ( 8u181, 7u191, and 6u201 ), may encounter an exception when establishing the connection.
The top most frames from Exception stack traces of applications encountering such issues might resemble the following:
javax.naming.ServiceUnavailableException: ; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
The issue has been resolved and the fix is available in the following releases:
- 8u181
- 7u191
See JDK-8211107

Java Expiration Date

The expiration date for 8u191 is January 15, 2019. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u191) on February 15, 2019. 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.

Bug Fixes

This release 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 8u191 Bug Fixes page.

» 8u191 Release notes

Java 8 Update 181 (8u181)

Release Highlights

IANA Data 2018e
JDK 8u181 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.
Removed Feature: Removal of Java DB
Java DB, also known as Apache Derby, has been removed in this release.
We recommend that you obtain the latest Apache Derby directly from the Apache project at:
https://db.apache.org/derby
JDK-8197871 (not public)
Change: Improve LDAP support
Endpoint identification has been enabled on LDAPS connections.
To improve the robustness of LDAPS (secure LDAP over TLS ) connections, endpoint identification algorithms have been enabled by default.
Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.
Define this system property (or set it to true) to disable endpoint identification algorithms.
JDK-8200666 (not public)
Change: Better stack walking
New access checks have been added during the object creation phase of deserialization. This should not affect ordinary uses of deserialization. However, reflective frameworks that make use of JDK-internal APIs may be impacted. The new checks can be disabled if necessary by setting the system property jdk.disableSerialConstructorChecks to the value "true". This must be done by adding the argument -Djdk.disableSerialConstructorChecks=true to the Java command line.
JDK-8197925 (not public)
Bug Fix: JVM Crash during G1 GC
A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the ClassLoaderData/SystemDictionary, and its _java_mirror or _class_loader fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass.
See JDK-8187577
Bug Fix: Better stability with older NUMA libraries (-XX+UseNuma)
A fix included in JDK 8 Update 152 introduced a regression that might cause the HotSpot JVM to crash during startup when the UseNUMA flag is used on Linux systems with versions of libnuma older than 2.0.9. This issue has been resolved.
See JDK-8198794

Java Expiration Date

The expiration date for 8u181 is October 16, 2018. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u181) on November 16, 2018. 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.

Bug Fixes

» 8u181 Release notes

Java 8 Update 171 (8u171)

Release Highlights

IANA Data 2018c
JDK 8u171 contains IANA time zone data version 2018c. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Enhanced KeyStore Mechanisms
A new security property named jceks.key.serialFilter has been introduced. If this filter is configured, the JCEKS KeyStore uses it during the deserialization of the encrypted Key object stored inside a SecretKeyEntry. If it is not configured or if the filter result is UNDECIDED (for example, none of the patterns match), then the filter configured by jdk.serialFilter is consulted.
If the system property jceks.key.serialFilter is also supplied, it supersedes the security property value defined here.
The filter pattern uses the same format as jdk.serialFilter. The default pattern allows java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type, and javax.crypto.spec.SecretKeySpec but rejects all the others.
Customers storing a SecretKey that does not serialize to the above types must modify the filter to make the key extractable.
JDK-8189997 (not public)
New Feature: System Property to Disable JRE Last Usage Tracking
A new system property jdk.disableLastUsageTracking has been introduced to disable JRE last usage tracking for a running VM. This property can be set in the command line by using either -Djdk.disableLastUsageTracking=true or -Djdk.disableLastUsageTracking. With this system property set, JRE last usage tracking will be disabled regardless of the com.oracle.usagetracker.track.last.usage property value set in usagetracker.properties.
JDK-8192039 (not public)
Note: CipherOutputStream Usage
The specification of javax.crypto.CipherOutputStream has been clarified to indicate that this class catches BadPaddingException and other exceptions thrown by failed integrity checks during decryption. These exceptions are not re-thrown, so the client is not informed that integrity checks have failed. Because of this behavior, this class may not be suitable for use with decryption in an authenticated mode of operation (for example, GCM) if the application requires explicit notification when authentication fails. These applications can use the Cipher API directly as an alternative to using this class.
JDK-8182362 (not public)
Change: Additional TeliaSonera Root Certificate
"TeliaSonera Root CA v1" has been added to the cacerts keystore.
JDK-8190851 (not public)
Change: XML Signatures Signed with EC Keys Less Than 224 Bits Disabled
To improve the strength of SSL/TLS connections, 3DES cipher suites have been disabled in SSL/TLS connections in the JDK via the jdk.tls.disabledAlgorithms Security Property.
JDK-8175075 (not public)
Bug Fix: Server-side HTTP-tunneled RMI Connections Disabled
Server side HTTP-tunneled RMI connections have been disabled by default in this release. This behavior can be reverted by setting the runtime property sun.rmi.server.disableIncomingHttp property to false. Note, this should not be confused with the sun.rmi.server.disableHttp property, which disables HTTP-tunneling on the client side and is false by default.
JDK-8193833 (not public)

Java Expiration Date

The expiration date for 8u171 is July 17, 2018. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u171) on August 17, 2018. 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.

Bug Fixes

» 8u171 Release notes

Java 8 Update 161 (8u161)

Release Highlights

IANA Data 2017c
JDK 8u161 contains IANA time zone data version 2017c. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits
Enhance the JDK security providers to support 3072-bit DiffieHellman and DSA parameters generation, pre-computed DiffieHellman parameters up to 8192 bits and pre-computed DSA parameters up to 3072 bits.
See JDK-8072452
New Feature: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
The JDK SunJSSE implementation now supports the TLS FFDHE mechanisms defined in RFC 7919. If a server cannot process the supported_groups TLS extension or the named groups in the extension, applications can either customize the supported group names with jdk.tls.namedGroups, or turn off the FFDHE mechanisms by setting the System Property jsse.enableFFDHEExtension to false.
See JDK-8140436
New Feature: Add additional IDL stub type checks to org.omg.CORBA.ORBstring_to_object method
Applications that either explicitly or implicitly call org.omg.CORBA.ORB.string_to_object, and wish to ensure the integrity of the IDL stub type involved in the ORB::string_to_object call flow, should specify additional IDL stub type checking. This is an "opt in" feature and is not enabled by default.
To take advantage of the additional type checking, the list of valid IDL interface class names of IDL stub classes is configured by one of the following:
- Specifying the security property com.sun.CORBA.ORBIorTypeCheckRegistryFilter located in the file conf/security/java.security in Java SE 9 or in jre/lib/security/java.security in Java SE 8 and earlier.
- Specifying the system property com.sun.CORBA.ORBIorTypeCheckRegistryFilter with the list of classes. If the system property is set, its value overrides the corresponding property defined in the java.security configuration.
If the com.sun.CORBA.ORBIorTypeCheckRegistryFilter property is not set, the type checking is only performed against a set of class names of the IDL interface types corresponding to the built-in IDL stub classes.
JDK-8160104 (not public)
Change: RSA public key validation
In 8u161, the RSA implementation in the SunRsaSign provider will reject any RSA public key that has an exponent that is not in the valid range as defined by PKCS#1 version 2.2. This change will affect JSSE connections as well as applications built on JCE.
JDK-8174756 (not public)
Change: Restrict Diffie-Hellman keys less than 1024 bits
Diffie-Hellman keys less than 1024 bits are considered too weak to use in practice and should be restricted by default in SSL/TLS/DTLS connections. Accordingly, Diffie-Hellman keys less than 1024 bits have been disabled by default by adding "DH keySize < 1024" to the "jdk.tls.disabledAlgorithms" security property in the java.security file. Although it is not recommended, administrators can update the security property ("jdk.tls.disabledAlgorithms") and permit smaller key sizes (for example, by setting "DH keySize < 768").
JDK-8148108 (not public)
Change: Provider default key size is updated
This change updates the JDK providers to use 2048 bits as the default key size for DSA instead of 1024 bits when applications have not explicitly initialized the java.security.KeyPairGenerator and java.security.AlgorithmParameterGenerator objects with a key size.
If compatibility issues arise, existing applications can set the system property jdk.security.defaultKeySize introduced in JDK-8181048 with the algorithm and its desired default key size.
JDK-8178466 (not public)

Java Expiration Date

The expiration date for 8u161 is April 17, 2018. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u161) on May 17, 2018. 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.

Bug Fixes

» 8u161 Release notes

Java 8 Update 151 (8u151)

Release Highlights

IANA Data 2017b
JDK 8u151 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.
Certificate Changes: Remove revoked Swisscom root certificate "swisscomrootevca2"
One Swisscom root certificate has been revoked by Swisscom and has been removed: Swisscom Root EV CA 2 alias: "swisscomrootevca2 [jdk]" DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=chJDK-8186330 (not public)
New Features New Security property to control crypto policy
This release introduces a new feature whereby the JCE jurisdiction policy files used by the JDK can be controlled via a new Security property. In older releases, JCE jurisdiction files had to be downloaded and installed separately to allow unlimited cryptography to be used by the JDK. The download and install steps are no longer necessary. To enable unlimited cryptography, one can use the new crypto.policy Security property. If the new Security property (crypto.policy) is set in the java.security file, or has been set dynamically by using the Security.setProperty() call before the JCE framework has been initialized, that setting will be honored. By default, the property will be undefined. If the property is undefined and the legacy JCE jurisdiction files don't exist in the legacy lib/security directory, then the default cryptographic level will remain at 'limited'. To configure the JDK to use unlimited cryptography, set the crypto.policy to a value of 'unlimited'. See the notes in the java.security file shipping with this release for more information.
Note: On Solaris, it's recommended that you remove the old SVR4 packages before installing the new JDK updates. If an SVR4 based upgrade (without uninstalling the old packages) is being done on a JDK release earlier than 6u131, 7u121, 8u111, then you should set the new crypto.policy Security property in the java.security file.

Because the old JCE jurisdiction files are left in <java-home>/lib/security, they may not meet the latest security JAR signing standards, which were refreshed in 6u131, 7u121, 8u111, and later updates. An exception similar to the following might be seen if the old files are used:

Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
See JDK-8157561
Changes Refactor existing providers to refer to the same constants for default values for key length
Two important changes have been made for this issue:
1. A new system property has been introduced that allows users to configure the default key size used by the JDK provider implementations of KeyPairGenerator and AlgorithmParameterGenerator. This property is named "jdk.security.defaultKeySize" and the value of this property is a list of comma-separated entries. Each entry consists of a case-insensitive algorithm name and the corresponding default key size (in decimal) separated by ':'. In addition, white space is ignored.
By default, this property will not have a value, and JDK providers will use their own default values. Entries containing an unrecognized algorithm name will be ignored. If the specified default key size is not a parseable decimal integer, that entry will be ignored as well.
1. The DSA KeyPairGenerator implementation of the SUN provider no longer implements java.security.interfaces.DSAKeyPairGenerator. Applications which cast the SUN provider's DSA KeyPairGenerator object to a java.security.interfaces.DSAKeyPairGenerator can set the system property "jdk.security.legacyDSAKeyPairGenerator". If the value of this property is 'true', the SUN provider will return a DSA KeyPairGenerator object which implements the java.security.interfaces.DSAKeyPairGenerator interface. This legacy implementation will use the same default value as specified by the javadoc in the interface.
By default, this property will not have a value, and the SUN provider will return a DSA KeyPairGenerator object which does not implement the forementioned interface and thus can determine its own provider-specific default value as stated in the java.security.KeyPairGenerator class or by the 'jdk.security.defaultKeySize' system property if set.
JDK-8181048 (not public)

Java Expiration Date

The expiration date for 8u151 is January 16, 2018. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u151) on February 16, 2018. 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.

Bug Fixes

» 8u151 Release notes

Java 8 Update 144 (8u144)

Release Highlights

IANA Data 2017b
JDK 8u144 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a / ended entry name for directory entry
java.util.zip.ZipEntry API doc specifies 'A directory entry is defined to be one whose name ends with a /'. However, in previous JDK releases, java.util.zip.ZipFile.getEntry(String entryName) may return a ZipEntry instance with an entry name that does not end with / for an existing zip directory entry when the passed in argument entryName does not end with a / and there is a matching zip directory entry with name entryName + / in the zip file. With this release, the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with / for any zip directory entry.
To revert to the previous behavior, set the system property jdk.util.zip.ensureTrailingSlash to 'false'.

This change was made in order to fix a regression introduced in JDK 8u141 when verifying signed JARs and has caused some WebStart applications to fail to load.
See JDK-8184993

Java Expiration Date

The expiration date for 8u144 is October 17, 2017. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u144) on November 17, 2017. 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.

Bug Fixes

» 8u144 Release notes

Java 8 Update 141 (8u141)

Release Highlights

IANA Data 2017b
JDK 8u141 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.
Certificate Changes: New Let's Encrypt certificates added to root CAs
One new root certificate has been added:
ISRG Root X1 alias: letsencryptisrgx1 DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (not public)
JMX Diagnostic improvements
com.sun.management.HotSpotDiagnostic::dumpHeap API is modified to throw IllegalArgumentException if the supplied file name does not end with “.hprof” suffix. Existing applications which do not provide a file name ending with the “.hprof” extension will fail with IllegalArgumentException. In that case, applications can either choose to handle the exception or restore old behavior by setting system property 'jdk.management.heapdump.allowAnyFileSuffix' to true.
JDK-8176055 (not public)
Tighter secure checks on processing WSDL files by wsimport tool
The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:
- DOCTYPE declaration is disallowed in documents
- External general entities are not included by default
- External parameter entities are not included by default
- External DTDs are completely ignored
To restore the previous behavior:
- Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
- Use the wsimport tool command line option –disableXmlSecurity
  NOTE: JDK 7 and JDK 6 support for this option in wsimport will be provided via a Patch release post July CPU
JDK-8182054 (not public)
Custom HostnameVerifier enables SNI extension
Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body.
See JDK-8144566
Improved algorithm constraints checking
With the need to restrict weak algorithms usage in situations where they are most vulnerable, additional features have been added when configuring the jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms security properties in the java.security file.
jdk.certpath.disabledAlgorithms: The certpath property has seen the most change. Previously it was limited to two Constraint types; either a full disabling of an algorithm by name or a full disabling of an algorithm by the key size when checking certificates, certificate chains, and certificate signatures. This creates configurations that are absolute and lack flexibility in their usage. Three new Constraints were added to give more flexibility in allowing and rejecting certificates.

"jdkCA" examines the certificate chain termination with regard to the cacerts file. In the case of "SHA1 jdkCA". SHA1's usage is checked through the certificate chain, but the chain must terminate at a marked trust anchor in the cacerts keystore to be rejected. This is useful for organizations that have their own private CA that trust using SHA1 with their trust anchor, but want to block certificate chains anchored by a public CA from using SHA1.

"denyAfter" checks if the given date is before the current date or the PKIXParameter date. In the case of "SHA1 denyAfter 2018-01-01", before 2018 a certificate with SHA1 can be used, but after that date, the certificate is rejected. This can be used for a policy across an organization that is phasing out an algorithm with a drop-dead date. For signed JAR files, the date is compared against the TSA timestamp. The date is specified in GMT.

"usage" examines the specified algorithm for a specified usage. This can be used when disabling an algorithm for all usages is not practical. There are three usages that can be specified:
- 'TLSServer' restricts the algorithm in TLS server certificate chains when server authentication is performed as a client.
- 'TLSClient' restricts the algorithm in TLS client certificate chains when client authentication is performed as a server.
- 'SignedJAR' restricts the algorithms in certificates in signed JAR files. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter.
  For example, "SHA1 usage TLSServer TLSClient" would disallow SHA1 certificates for TLSServer and TLSClient operations, but SignedJars would be allowed
All of these constraints can be combined to constrain an algorithm when delimited by '&'. For example, to disable SHA1 certificate chains that terminate at marked trust anchors only for TLSServer operations, the constraint would be "SHA1 jdkCA & usage TLSServer".

jdk.jar.disabledAlgorithms: One additional constraint was added to this .jar property to restrict JAR manifest algorithms.

"denyAfter" checks algorithm constraints on manifest digest algorithms inside a signed JAR file. The date given in the constraint is compared against the TSA timestamp on the signed JAR file. If there is no timestamp or the timestamp is on or after the specified date, the signed JAR file is treated as unsigned. If the timestamp is before the specified date, the .jar will operate as a signed JAR file. The syntax for restricting SHA1 in JAR files signed after January 1st 2018 is: "SHA1 denyAfter 2018-01-01". The syntax is the same as that for the certpath property, however certificate checking will not be performed by this property.
See JDK-8176536

Java Expiration Date

The expiration date for 8u141 is October 17, 2017. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u141) on November 17, 2017. 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.

Bug Fixes

» 8u141 Release notes

Java 8 Update 131 (8u131)

Release Highlights

IANA Data 2016j
JDK 8u131 contains IANA time zone data version 2016j. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Introduce new window ordering model
On the OS X platform, the AWT framework used native services to implement parent-child relationship for windows. That caused some negative visual effects especially in multi-monitor environments. To get rid of the disadvantages of such an approach, the new window ordering model, which is fully implemented at the JDK layer, was introduced. Its main principles are listed below:
- A window should be placed above its nearest parent window.
- If a window has several child windows, all child windows should be located at the same layer and the window from the active window chain should be ordered above its siblings.
- Ordering should not be performed for a window which is in an iconified state or when the transition to an iconified state is in progress.
These rules are applied to every frame or dialog from the window hierarchy that contains the currently focused window. See JDK-8169589
Bug Fix: Correction of IllegalArgumentException from TLS handshake
A recent issue from the JDK-8173783 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See JDK-8173783
MD5 added to jdk.jar.disabledAlgorithms Security property
This JDK release introduces a new restriction on how MD5 signed JAR files are verified. If the signed JAR file uses MD5, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:
- Applets or Web Start Applications
- Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR.
The list of disabled algorithms is controlled via the security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

To check if a weak algorithm or key was used to sign a JAR file, one can use the jarsigner binary that ships with this JDK. Running "jarsigner -verify" on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use the following command:

jarsigner -verify test.jar

If the file in this example was signed with a weak signature algorithm like MD5withRSA, the following output would be displayed:

The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details.

More details can be displayed by using the verbose option:

jarsigner -verify -verbose test.jar

The following output would be displayed:
```
- Signed by "CN=weak_signer"
    Digest algorithm: MD5 (weak)
    Signature algorithm: MD5withRSA (weak), 512-bit key (weak)
  Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
    Timestamp digest algorithm: SHA-256
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key
```
To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JARs, the existing signature(s) should be removed from the JAR file. This can be done with the zip utility, as follows:

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA'

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components. JDK-8171121 (not public)
New system property to control caching for HTTP SPNEGO connection.
A new JDK implementation specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections remains enabled by default, so if the property is not explicitly specified, there will be no behavior change. When connecting to an HTTP server which uses SPNEGO to negotiate authentication, and when connection and authentication with the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP server using SPNEGO usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol in order to force requesting new authentication with each new requests to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP SPNEGO connections. If jdk.spnego.cache is defined and evaluates to false, then all caching will be disabled for HTTP SPNEGO connections. Setting this system property to false may, however, result in undesirable side effects:
- Performance of HTTP SPNEGO connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
- Credentials will need to be obtained again for each new requests, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.
JDK-8170814 (not public)
New system property to control caching for HTTP NTLM connection.
A new JDK implementation specific system property to control caching for HTTP NTLM connection is introduced. Caching for HTTP NTLM connection remains enabled by default, so if the property is not explicitly specified, there will be no behavior change. On some platforms, the HTTP NTLM implementation in the JDK can support transparent authentication, where the system user credentials are used at system level. When transparent authentication is not available or unsuccessful, the JDK only supports getting credentials from a global authenticator. If connection to the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP NTLM server usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP NTLM protocol in order to force requesting new authentication with each new requests to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP NTLM connections. If jdk.ntlm.cache is defined and evaluates to false, then all caching will be disabled for HTTP NTLM connections. Setting this system property to false may, however, result in undesirable side effects:
- Performance of HTTP NTLM connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
- Credentials will need to be obtained again for each new requests, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.
JDK-8163520 (not public)
New version of VisualVM
VisualVM 1.3.9 was released on October 4th, 2016 http://visualvm.github.io/relnotes.html and has been integrated into 8u131. See JDK-8167485

Java Expiration Date

The expiration date for 8u131 is July 18, 2017. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u131) on August 18, 2017. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory. For a list of bug fixes included in this release, see JDK 8u131 Bug Fixes page.

» 8u131 Release notes

Java 8 Update 121 (8u121)

Release Highlights

IANA Data 2016i
JDK 8u121 contains IANA time zone data version 2016i. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Trackpad scrolling of text on OS X 10.12 Sierra is very fast
The MouseWheelEvent.getWheelRotation() method returned rounded native NSEvent deltaX/Y events on Mac OS X. The latest macOS Sierra 10.12 produces very small NSEvent deltaX/Y values so rounding and summing them leads to the huge value returned from the MouseWheelEvent.getWheelRotation(). The JDK-8166591 fix accumulates NSEvent deltaX/Y and the MouseWheelEvent.getWheelRotation() method returns non-zero values only when the accumulated value exceeds a threshold and zero value. This is compliant with the MouseWheelEvent.getWheelRotation() specification: "Returns the number of 'clicks' the mouse wheel was rotated, as an integer. A partial rotation may occur if the mouse supports a high-resolution wheel. In this case, the method returns zero until a full 'click' has been accumulated." For the precise wheel rotation values, use the MouseWheelEvent.getPreciseWheelRotation() method instead. See JDK-8166591
Improve the default strength of EC in JDK
To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the jdk.certpath.disabledAlgorithms Security Property) and SSL/TLS connections (via the jdk.tls.disabledAlgorithms Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS implementation in JDK. The new System Property, jdk.tls.namedGroups, defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example:
```
    jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"
```
Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. See JDK-8148516
New --allow-script-in-comments option for javadoc
The javadoc tool will now reject any occurrences of JavaScript code in the javadoc documentation comments and command-line options, unless the command-line option, --allow-script-in-comments is specified. With the --allow-script-in-comments option, the javadoc tool will preserve JavaScript code in documentation comments and command-line options. An error will be given by the javadoc tool if JavaScript code is found and the command-line option is not set.
JDK-8138725 (not public)
Increase the minimum key length to 1024 for XML Signatures
The secure validation mode of the XML Signature implementation has been enhanced to restrict RSA and DSA keys less than 1024 bits by default as they are no longer secure enough for digital signatures. Additionally, a new security property named jdk.xml.dsig.SecureValidationPolicy has been added to the java.security file and can be used to control the different restrictions enforced when the secure validation mode is enabled. The secure validation mode is enabled either by setting the xml signature property org.jcp.xml.dsig.secureValidation to true with the javax.xml.crypto.XMLCryptoContext.setProperty method, or by running the code with a SecurityManager. If an XML Signature is generated or validated with a weak RSA or DSA key, an XMLSignatureException will be thrown with the message "RSA keys less than 1024 bits are forbidden when secure validation is enabled" or "DSA keys less than 1024 bits are forbidden when secure validation is enabled".
JDK-8140353 (not public)
Restrict certificates with DSA keys less than 1024 bits
DSA keys less than 1024 bits are not strong enough and should be restricted in certification path building and validation. Accordingly, DSA keys less than 1024 bits have been deactivated by default by adding "DSA keySize < 1024" to the "jdk.certpath.disabledAlgorithms" security property. Applications can update this restriction in the security property ("jdk.certpath.disabledAlgorithms") and permit smaller key sizes if really needed (for example, "DSA keySize < 768"). JDK-8139565 (not public)
More checks added to DER encoding parsing code
More checks are added to the DER encoding parsing code to catch various encoding errors. In addition, signatures which contain constructed indefinite length encoding will now lead to IOException during parsing. Note that signatures generated using JDK default providers are not affected by this change. JDK-8168714 (not public)
Additional access restrictions for URLClassLoader.newInstance
Class loaders created by the java.net.URLClassLoader.newInstance methods can be used to load classes from a list of given URLs. If the calling code does not have access to one or more of the URLs, and the URL artifacts that can be accessed do not contain the required class, then a ClassNotFoundException, or similar, will be thrown. Previously, a SecurityException would have been thrown when access to a URL was denied. If required to revert to the old behavior, this change can be disabled by setting the jdk.net.URLClassPath.disableRestrictedPermissions system property. JDK-8151934 (not public)
A new configurable property in logging.properties java.util.logging.FileHandler.maxLocks
A new "java.util.logging.FileHandler.maxLocks" configurable property is added to java.util.logging.FileHandler. This new logging property can be defined in the logging configuration file and makes it possible to configure the maximum number of concurrent log file locks a FileHandler can handle. The default value is 100. In a highly concurrent environment where multiple (more than 101) standalone client applications are using the JDK Logging API with FileHandler simultaneously, it may happen that the default limit of 100 is reached, resulting in a failure to acquire FileHandler file locks and causing an IO Exception to be thrown. In such a case, the new logging property can be used to increase the maximum number of locks before deploying the application. If not overridden, the default value of maxLocks (100) remains unchanged. See java.util.logging.LogManager and java.util.logging.FileHandler API documentation for more details. See JDK-8153955

Notes

Improved protection for JNDI remote class loading

Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set the following system property to the string "true", as appropriate:

    com.sun.jndi.rmi.object.trustURLCodebase
    com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (not public)

jarsigner -verbose -verify should print the algorithms used to sign the jar

The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak.

Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property jdk.jar.disabledAlgorithms, it will be labeled with "(weak)".

For example:

- Signed by "CN=weak_signer"
   Digest algorithm: MD2 (weak) 
   Signature algorithm: MD2withRSA (weak), 512-bit key (weak)
 Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
   Timestamp digest algorithm: SHA-256 
   Timestamp signature algorithm: SHA256withRSA, 2048-bit key

See JDK-8163304

Known Issues

javapackager and fx:deploy bundle the whole JDK instead of JRE

There is a known bug in the Java Packager for Mac where the entire JDK may be bundled with the application bundle resulting in an unusually large bundle. The work around is to use the bundler option -Bruntime option. For example: -Bruntime=JavaAppletPlugin.plugin where the JavaAppletPlugin.plugin for the desired JRE to bundle is located in the current directory. See JDK-8166835

Java Installation will fail for non-admin users with UAC off

The Java installation on Windows will fail without warning or prompting, for non-admin users with User Access Control (UAC) disabled. The installer will leave a directory, jds<number>.tmp, in the %TEMP% directory.
JDK-8161460 (not public)

New Features

Added security property to configure XML Signature secure validation mode

A new security property named jdk.xml.dsig.secureValidationPolicy has been added that allows you to configure the individual restrictions that are enforced when the secure validation mode of XML Signature is enabled. The default value for this property in the java.security configuration file is:

jdk.xml.dsig.secureValidationPolicy=\
    disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    maxTransforms 5,\
    maxReferences 30,\
    disallowReferenceUriSchemes file http https,\
    noDuplicateIds,\
    noRetrievalMethodLoops

Please refer to the definition of the property in the java.security file for more information. See JDK-8151893

Serialization Filter Configuration

Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" patterns are described in JEP 290 Serialization Filtering and in <JRE>/lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled. See JDK-8155760

RMI Better constraint checking

RMI Registry and Distributed Garbage Collection use the mechanisms of JEP 290 Serialization Filtering to improve service robustness. RMI Registry and DGC implement built-in white-list filters for the typical classes expected to be used with each service. Additional filter patterns can be configured using either a system property or a security property. The "sun.rmi.registry.registryFilter" and "sun.rmi.transport.dgcFilter" property pattern syntax is described in JEP 290 and in <JRE>/lib/security/java.security. JDK-8156802 (not public)

Add mechanism to allow non-default root CAs to not be subject to algorithm restrictions

In the java.security file, an additional constraint named "jdkCA" is added to the jdk.certpath.disabledAlgorithms property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example: To apply this constraint to SHA-1 certificates, include the following: SHA1 jdkCA
See JDK-8140422

Java Expiration Date

The expiration date for 8u121 is April 18, 2017. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u121) on May 18, 2017. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

» 8u121 Release notes

Java 8 Update 111 (8u111)

Release Highlights

IANA Data 2016f
JDK 8u111 contains IANA time zone data version 2016f. For more information, refer to Timezone Data Versions in the JRE Software. See JDK-8159684.
Certificate Changes: New JCE Code Signing Root CA
In order to support longer key lengths and stronger signature algorithms, a new JCE Provider Code Signing root certificate authority has been created and its certificate added to Oracle JDK. New JCE provider code signing certificates issued from this CA will be used to sign JCE providers from this point forward. By default, new requests for JCE provider code signing certificates will be issued from this CA.

Existing certificates from the current JCE provider code signing root will continue to validate. However, this root CA may be disabled at some point in the future. We recommend that new certificates be requested and existing provider JARs be re-signed. For details on the JCE provider signing process, please refer to the How to Implement a Provider in the Java Cryptography Architecture documentation. JDK-8141340 (not public)
Service Menu services
The lifecycle management of AWT menu components exposed problems on certain platforms. This fix improves state synchronization between menus and their containers. JDK-8158993 (not public)
Disable Basic authentication for HTTPS tunneling
In some environments, certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding Basic to the jdk.http.auth.tunneling.disabledSchemes networking property. Now, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line. Additionally, the jdk.http.auth.tunneling.disabledSchemes and jdk.http.auth.proxying.disabledSchemes networking properties, and system properties of the same name, can be used to disable other authentication schemes that may be active when setting up a tunnel for HTTPS, or proxying plain HTTP, respectively. JDK-8160838 (not public)
Restrict JARs signed with weak algorithms and keys
This JDK release introduces new restrictions on how signed JAR files are verified. If the signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR file as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:
1. Applets or Web Start Applications
2. Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR.

The list of disabled algorithms is controlled via a new security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

The following algorithms and key sizes are restricted in this release:
1. MD2 (in either the digest or signature algorithm)
2. RSA keys less than 1024 bits
NOTE: We are planning to restrict MD5-based signatures in signed JARs in the April 2017 CPU.

To check if a weak algorithm or key was used to sign a JAR file, you can use the jarsigner binary that ships with this JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use the following command:
jarsigner -verify -J-Djava.security.debug=jar test.jar

If the file in this example was signed with a weak signature algorithm like MD2withRSA, the following output would be displayed:
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!

The updated jarsigner command will exit with the following warning printed to standard output:
"Signature not parsable or verifiable. The jar will be treated as unsigned. The jar may have been signed with a weak algorithm that is now disabled. For more information, rerun jarsigner with debug enabled (-J-Djava.security.debug=jar)"

To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JAR files, the existing signature(s) should be removed from the JAR. This can be done with the zip utility, as follows:

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JAR files and other security components. In particular, please note the current plan is to restrict MD5-based signatures in signed JAR files in the April 2017 CPU.

To test if your JARs have been signed with MD5, add MD5 to the jdk.jar.disabledAlgorithms security property, ex:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

and then run jarsigner -verify -J-Djava.security.debug=jar on your JAR files as described above.
JDK-8155973 (not public)
Warning message added to deployment authenticator dialog
A warning has been added to the plugin authentication dialog in cases where HTTP Basic authentication (credentials are sent unencrypted) is used while using a proxy or while not using SSL/TLS protocols:
"WARNING: Basic authentication scheme will effectively transmit your credentials in clear text. Do you really want to do this?"
JDK-8161647 (not public)

Known Issues

Some events not available in JFR recordings on Windows

The following events are not available in the JFR recordings on Windows for release 8u111:

hotspot/jvm/os/processor/cpu_load
os/processor/context_switch_rate

This is due to regression JDK-8063089 that was introduced in 8u111 with the changes for JDK-8162419. The fix for JDK-8063089 could not be included in the 8u111 release. It will be available in the next 8u111 BPR build and in the next public release.
JDK-8063089 (not public)

JVM throws NullPointerExceptions on macOS Sierra 10.12

On macOS Sierra 10.12, if a user presses modifier keys (such as Command, Shift, or Alt) while an applet is running in a browser, an error box named "Internal Error" might be displayed. It will also show the "exec" icon in the macOS dock. The user can dismiss the applet, or try to rerun the applet while not pressing a modifier key. See JDK-8165867.

Java Expiration Date

The expiration date for 8u111 is January 17, 2017. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u111) on February 17, 2017. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

» 8u111 Release notes

Java 8 Update 101 (8u101)

Release Highlights

IANA Data 2016d
JDK 8u101 contains IANA time zone data version 2016d. For more information, refer to Timezone Data Versions in the JRE Software. See JDK-8151876.
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 Iden 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.
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 behavior 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
MSCAPI KeyStore can handle same-named certificates
Java SE KeyStore does not allow certificates that have the same aliases. 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."
See JDK-6483657.
Deployment Tookit API methods no longer install JRE
The Deployment Toolkit API installLatestJRE() and installJRE(requestedVersion) methods from deployJava.js and the install() method from dtjava.js no longer install the JRE. If a user's version of Java is below the security baseline, it redirects the user to java.com to get an updated JRE. JDK-8148310 (not public)
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)

Known Issues

JRE 8u101 is not recognized by Internet Explorer (IE) when using static class ID

When a static class id is used to launch an applet or web start application while using JRE 8u101, users will get an unwanted dialog box stating that they either use the latest JRE or cancel the launch even though they have installed and are using the latest JRE (JRE 8u101). This specific case is only applicable on Windows and IE.

We do not recommend using static class id for JRE version selection (since JDK 5u6, December 2005) as per http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

To workaround this issue, users can do one of the following two things:

Hit launch with the latest version (8u101) and ignore the warning.
Install JRE 8u102 instead of JRE 8u101 to avoid this issue.

To address this issue, developers can do one of the following two things:

Use a dynamic class id instead of static class id.
Use java_version when using an HTML applet or a JNLP descriptor when using JNLP.

JDK-8147457 (not public)

Bug Fixes

Java Expiration Date

The expiration date for 8u101 is October 19, 2016. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u101) on November 19, 2016. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

» 8u101 Release notes

Java 8 Update 91 (8u91)

Release Highlights

IANA Data 2016a
JDK 8u91 contains IANA time zone data version 2016a. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Regression in Applet startup time fixed
JDK-8080977 introduced delay on applet launch. The delay appears only on IE and lasts about 20 seconds. JDK-8136759 removed this delay. See JDK-8136759
Bug Fix: DSA signature generation is now subject to a key strength check
For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (e.g. using (2048, 256)-bit DSA keys with SHA1withDSA signature), the operation will fail with the error message: "The security strength of SHA1 digest algorithm is not sufficient for this key size." JDK-8138593 (not public)
Bug Fix: Firefox 42 liveconnect problem
Because it might cause the browser to hang, we don't process JavaScript-to-Java calls when the Java plugin is launched from plugin-container.exe (the default behavior for Firefox 42) and the applet status is not Ready(2). If the applet is not ready (the status is not 2), we don't execute the actual Java method and only return null.

If the plugin is launched from plugin-container.exe, do not use JavaScript-To-Java calls that may require more than 11 seconds(the default value of dom.ipc.plugins.hangUITimeoutSecs) to be completed or show a modal dialog during JavaScript-To-Java call. In this case, the main browser thread must be blocked, which might cause the browser to hang and the plugin to terminate.

Workaround for Firefox 42: Users can set dom.ipc.plugins.enabled=false. The side effect of this workaround is that it changes the setting for all plugins. JDK-8144079 (not public)
Bug Fix: New attribute for JMX RMI JRMP servers specifies a list of class names to use when deserializing server credentials
A new java attribute has been defined for the environment to allow a JMX RMI JRMP server to specify a list of class names. These names correspond to the closure of class names that are expected by the server when deserializing credentials. For instance, if the expected credentials were a
```
 List<string>
```
, then the closure would constitute all the concrete classes that should be expected in the serial form of a list of Strings.

By default, this attribute is used only by the default agent with the following:
```
 {   
   "[Ljava.lang.String;",   
   "java.lang.String" 
 } 
```
Only arrays of Strings and Strings will be accepted when deserializing the credentials. The attribute name is:
```
"jmx.remote.rmi.server.credential.types"
```
The following is an example of a user starting a server with the specified credentials class names:
```
Map<String, Object> env = new HashMap<>(1);
 env.put ( 
 "jmx.remote.rmi.server.credential.types",
   new String[]{
   String[].class.getName(),
   String.class.getName()
   }
   );
   JMXConnectorServer server
   = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer);
```
The new feature should be used by directly specifying:
"jmx.remote.rmi.server.credential.types"

JDK-8144430 (not public)
Bug Fix: Disable MD5withRSA signature algorithm in the JSSE provider
The MD5withRSA signature algorithm is now considered insecure and should no longer be used. Accordingly, MD5withRSA has been deactivated by default in the Oracle JSSE implementation by adding "MD5withRSA" to the "jdk.tls.disabledAlgorithms" security property. Now, both TLS handshake messages and X.509 certificates signed with MD5withRSA algorithm are no longer acceptable by default. This change extends the previous MD5-based certificate restriction ("jdk.certpath.disabledAlgorithms") to also include handshake messages in TLS version 1.2. If required, this algorithm can be reactivated by removing "MD5withRSA" from the "jdk.tls.disabledAlgorithms" security property. JDK-8144773 (not public)
Bug Fix: New certificates added to root CAs
Eight new root certificates have been added :
- QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
- QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3
- QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
- DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
See JDK-8145954 and JDK-8145955.

Notes

Removal of Static JREs
Java installers for Windows that were released prior to version 8u91 did not remove statically installed JREs by default. In order to remove JREs that were installed statically, users had to manually select those JREs in the Java installer's user interface. Now in Java releases 8u91 and above, JREs that were installed statically will automatically be removed, if they are below the security baseline. For more information on static install, please see Java Runtime Environment Configuration.

Java Expiration Date

The expiration date for 8u91 is July 19, 2016. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u91) on August 19, 2016. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

» 8u91 Release notes

Java 8 Update 77 (8u77)

Release Highlights

IANA Data 2016a
JDK 8u77 contains IANA time zone data version 2016a. For more information, refer to Timezone Data Versions in the JRE Software.

Java Expiration Date

The expiration date for 8u77 is April 19, 2016. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u77) on May 19, 2016. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Notes

This Security Alert (8u77) is based off the earlier 8u74 PSU release. All users of earlier JDK 8 releases should update to this release. For more information on the difference between Critical Patch Updates and Patch Set Updates please visit Java CPU and PSU Releases Explained.

The demos, samples, and Documentation bundles for 8u77 are not impacted by the Security Alert for CVE-2016-0636, so version 8u73 demos, samples, and Documentation bundles remain the most up to-date version until the April Critical Patch Update release.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

» 8u77 Release notes

Java 8 Update 73 (8u73)

Release Highlights

IANA Data 2015g
JDK 8u71 contains IANA time zone data version 2015g. For more information, refer to Timezone Data Versions in the JRE Software.

Java Expiration Date

The expiration date for 8u73 is April 19, 2016. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u73) on May 19, 2016. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Notes

Oracle strongly recommends that Java users who have downloaded affected versions and plan future installations with these downloaded versions discard these old downloads. Java users who have installed the January 2016 Critical Patch Update versions of Java SE 6, 7, or 8 need take no action. Java users who have not installed the January 2016 Critical Patch Update versions of Java SE 6, 7, or 8 should upgrade to the Java SE 6, 7, or 8 releases from the Security Alert for CVE-2016-0603.

The demos, samples, and Documentation bundles for 8u73 are not impacted by the Security Alert for CVE-2016-0603, so version 8u71 demos, samples, and Documentation bundles remain the most up to-date version until the April Critical Patch Update release.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory. Note that 8u73 does not contain the PSU builds found in 8u72. Customers who require the additional bug fixes contained in 8u72 should update to 8u74 instead of 8u73.

» 8u73 Release notes

Java 8 Update 71 (8u71)

Release Highlights

IANA Data 2015g
JDK 8u71 contains IANA time zone data version 2015g. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Running jps as root does not show all information
After the fix of JDK-8050807 (fixed in 8u31, 7u75 and 6u91), running jps as root did not show all the information from Java processes started by other users on some systems. This has now been fixed. See JDK-8075773.
Bug Fix: Installers appearing stalled on ESC configurations
Users running Internet Explorer Enhance Security Configuration (ESC) on Windows Server 2008 R2 may have experienced issues installing Java in interactive mode. This issue has been resolved in the 8u71 release. Installers executed in interactive mode will no longer appear to be stalled on ESC configurations. See JDK-8140197.
Bug Fix: Problem with PBE algorithms using AES crypto corrected
An error was corrected for PBE using 256-bit AES ciphers such that the derived key may be different and not equivalent to keys previously derived from the same password. JDK-8138589 (not public).
Bug Fix: Default limit added for XML maximum entity size
A default limit for maximum entity size has been added. For more about XML processing limits, please see The Java Tutorials, Processing Limits. JDK-8133962 (not public)
Bug Fix: Problem with Enterprise MSI switch 'REMOVEOLDERJRES' documentation corrected
The Enterprise MSI documentation lists configuration options. The REMOVEOLDERJRES option used to uninstall old JREs was missing. Added this option, with the description:
If set to 1, removes older releases of the JRE installed on the system.
Default: 0 does not remove any old JREs
JDK-8081237 (not public)

Java Expiration Date

The expiration date for 8u71 is April 19, 2016. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u71) on May 19, 2016. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u71 Bug Fixes page.

» 8u71 Release notes

Java 8 Update 66 (8u66)

Release Highlights

8u66 build 18 addresses an issue on Firefox.

Bug Fix: _releaseObject called from wrong thread
A recent change to Firefox caused the _releaseObject call to be made from a thread other than the main thread. This may cause a race condition, which may inadvertently crash the browser. This has been addressed in build 18 of 8u66. For more information, see Bugs@Mozilla 1221448. See JDK-8133523.

Java plug-in does not work in Firefox after installing Java

Firefox 42 may crash when trying to run the Java plug-in. Workaround options are listed in the FAQ. See JDK-8142908 (not public).

Java Expiration Date

The expiration date for 8u66 is January 19, 2016. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u66) on February 19, 2016. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u66 Bug Fixes page.

» 8u66 Release notes

Java 8 Update 65 (8u65)

Release Highlights

IANA Data 2015f
JDK 8u65 contains IANA time zone data version 2015f. For more information, refer to Timezone Data Versions in the JRE Software.
Support ISO 4217 'Current funds codes' table (A.2)
This enhancement adds support for ISO 4217 table A.2 fund codes. Previously the JDK only supported those currencies listed in table A.1. See JDK-8074350.
Bug Fix: [mac osx] JRE AU client installed fails update to NEXTVER on Mac 10.11
A new installer is introduced in the 8u65 release to update OS X users to the latest version. The installer will apply to both scheduled and manual updates, and bundles made available on java.com and OTN. Users who experience compatibility issues with the new installer can manually download and install the ".pkg" installer available on My Oracle Support.
Bug Fix: Hotspot should use PICL interface to get cacheline size on SPARC
The libpicl library is now required on Solaris/SPARC to determine the size of the cache lines. In case the library is not present or the PICL service is not available the JVM will display a warning and compiler optimizations that utilize the BIS (Block Initializing Store) instruction will be turned off. See JDK-8056124.
Bug Fix: dns_lookup_realm should be false by default
The dns_lookup_realm setting in Kerberos' krb5.conf file is by default false. See JDK-8080637.
Bug Fix: Preloading libjsig.dylib causes deadlock when signal() is called
Applications need to preload the libjsig library to enable signal chaining. Previously, on OS X, after libjsig.dylib was preloaded, any call from native code to signal() caused a deadlock. This has been corrected. See JDK-8072147.
Bug Fix: Better group dynamics
In OpenJDK SSL/TLS/DTLS implementation (SunJSSE provider), safe prime Diffie-Hellman groups are used by default. Users can custom Diffie-Hellman groups via Security Property, jdk.tls.server.defaultDHEParameters.
Bug Fix: VM crash when class is redefined with Instrumentation.redefineClasses
The JVM could crash when a class was redefined with Instrumentation.redefineClasses(). The crash could either be a segmentation fault at SystemDictionary::resolve_or_null, or an internal error with the message 'tag mismatch with resolution error table'. This has now been fixed. See JDK-8076110.

Notes

When running on OSX 10.11 El Capitan, when SIP is enabled, certain environment variables intended for debugging applications, such as DYLD_LIBRARY_PATH, may be stripped from the environment when running Java from the command line or when double-clicking a JAR file. Applications should not rely on these variables in a production environment, they are only intended for debugging during development.

MD5 must not be used for digital signatures where collision resistance is required. In orderto prevent the usage of MD5 as digital signature algorithm during X.509 certificate operations, MD5 is added to jdk.certpath.disabledAlgorithms security property. For those applications that still using MD5 signed certificate, please upgrade the weak certificate as soon as possible.

Known Issues

[macosx] Sponsor offer screen accessibility (a11y) issues
Users who operate the keyboard to access user interfaces in the Java installer will be unable to access hyperlinks and checkboxes in software add-on offer screens. As a workaround to setting preferences related to add-on software in the user interface, users can disable such offers either by disabling them in the Java control panel, or by passing SPONSORS=0 via the command line. For more information, refer to Install Java without sponsor offers FAQ. See JDK-8061886 (not public).

Java Expiration Date

The expiration date for 8u65 is January 19, 2016. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u65) on February 19, 2016. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u65 Bug Fixes page.

» 8u65 Release notes

Java 8 Update 60 (8u60)

Release Highlights

IANA Data 2015e
JDK 8u60 contains IANA time zone data version 2015e. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: dns_lookup_realm should be false by default
The dns_lookup_realm setting in Kerberos' krb5.conf file is by default false. See 8080637.
Bug Fix: Disable RC4 cipher suites
RC4-based TLS ciphersuites (e.g. TLS_RSA_WITH_RC4_128_SHA) are now considered compromised and should no longer be used (see RFC 7465). Accordingly, RC4-based TLS ciphersuites have been deactivated by default in the Oracle JSSE implementation by adding "RC4" to "jdk.tls.disabledAlgorithms" security property, and by removing them from the default enabled ciphersuites list. These cipher suites can be reactivated by removing "RC4" form "jdk.tls.disabledAlgorithms" security property in the java.security file or by dynamically calling Security.setProperty(), and also readding them to the enabled ciphersuite list using the SSLSocket/SSLEngine.setEnabledCipherSuites() methods. You can also use the -Djava.security.properties command line option to override the jdk.tls.disabledAlgorithms security property. For example:
java -Djava.security.properties=my.java.security ...
where my.java.security is a file containing the property without RC4:
jdk.tls.disabledAlgorithms=SSLv3
Even with this option set from commandline, the RC4 based ciphersuites need to be re-added to the enabled ciphersuite list by using the SSLSocket/SSLEngine.setEnabledCipherSuites() methods. See 8076221.
Bug Fix: Support keystore type detection for JKS and PKCS12 keystores
Keystore Compatibility Mode: To aid interoperability, the Java keystore type JKS now supports keystore compatibility mode by default. This mode enables JKS keystores to access both JKS and PKCS12 file formats. To disable keystore compatibility mode set the Security property keystore.type.compat to the string value false. See 8062552.
Bug Fix: Deprecate Unsafe monitor methods in JDK 8u release
The methods monitorEnter, monitorExit and tryMonitorEnter on sun.misc.Unsafe are marked as deprecated in JDK 8u60 and will be removed in a future release. These methods are not used within the JDK itself and are very rarely used outside of the JDK. See 8069302.
Bug Fix: Extract JFR recording from the core file using SA
DumpJFR is a Serviceability Agent based tool that can be used to extract Java Flight Recorder(JFR) data from the core files and live Hotspot processes. DumpJFR can be used in one of the following methods:
- Attach DumpJFR to a live process:
  
  java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>
- Attach DumpJFR to a core file:
  
  java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
DumpJFR tool dumps the JFR data to a file called recording.jfr in the current working folder. See 8065301 (not public).
Bug Fix: Local variables named 'enum' lead to spurious compiler crashes
The javac parser is incorrectly parsing local variables with name 'enum'; this results in spurious failures when a program containing such local variables is compiled with a 'source' flag corresponding to a release in which the enum construct is not available (such as '-source 1.4'). See 8069181.

Java Development Kit for ARM Release 8u60

This release includes Java Development Kit for ARM Release 8u60 (JDK 8u60 for ARM). For ARM device support information, see JDK for ARM Downloads page. For system requirements, installation instructions and troubleshooting tips, see Installation Instructions page.

Limitation: Native Memory Tracking support is limited in JDK for ARM. The java command line option XX:NativeMemoryTracking=detail is not supported for ARM targets (an error message is displayed to user). Instead, use the following option:
XX:NativeMemoryTracking=summary

Documentation Updates due to Nashorn Enhancements

JDK 8u60 includes new enhancements to Nashorn. As a result the following documentation changes should be read in conjunction with the current Nashorn documentation:

Addition: In the previous section, we mentioned that every JavaScript object when exposed to Java APIs implements the java.util.Map interface. This is true even for JavaScript arrays. However, this behavior is often not desired or expected when the Java code expects JSON-parsed objects. Java libraries that manipulate JSON-parsed objects usually expect arrays to expose the java.util.List interface instead. If you need to expose your JavaScript objects so that arrays are exposed as lists and not maps, you can use the Java.asJSONCompatible(obj) function, where obj is the root of your JSON object tree.
Correction: The caution mentioned at the end of Mapping Data Types section, is no longer applicable. Nashorn ensures that internal JavaScript strings are converted to java.lang.String when exposed externally.
Correction: The statement in the section Mapping Data Types, that mentions "For example, arrays must be explicitly converted,..." is not correct. Arrays are automatically converted to Java array types, such as java.util.List, java.util.Collection, java.util.Queue and java.util.Deque and so on.

Changes in Deployment Rule Set v1.2

JDK 8u60 implements Deployment Rule Set (DRS) 1.2, which includes the following changes:

Add "checksum" element as sub element of "id" which can allow unsigned jars to be identified by the SHA-256 checksum of the uncompressed form of a jar:
- The "checksum" element will match only unsigned jars, and the given hash will be compared only against the uncompressed form of the jar.
- The "checksum" element (similar to "certificate" element) has two arguments "hash" and "algorithm", however, unlike "certificate" element, the only supported value for "algorithm" is "SHA-256". Any other value provided will be ignored.
Allow "message" element to apply to all rule types, where previously it only applied to a block rule:
- In a run rule, a message sub element will cause a message dialog to be displayed where without a run rule, the default behavior would be to show certificate or unsigned dialog. The message will be displayed in the message dialog.
- In a default rule, the message will only be displayed if the default action is to block. In such a case the message will be included in the block dialog.
Echo "customer" blocks in the Java Console, trace files, and Java Usage Tracker records.
- Previous to DRS 1.2, "customer" elements could be included (with any sub-elements) in the ruleset.xml file. This element and all its sub elements are ignored. In DRS 1.2, the elements are still functionally ignored. However:
  - When parsing the ruleset.xml file, all "customer" blocks will be echoed to the Java Console and deployment trace file (if Console and Tracing are enabled).
  - When using a rule, all "customer" records included within that rule will be added to the Java Usage Tracker (JUT) record (if JUT is enabled).

As a result of the above changes, the DTD for DRS 1.2 is as follows:

<!ELEMENT ruleset (rule*)>
<!ATTRIBUTE ruleset href CDATA #IMPLIED>
<!ATTRIBUTE ruleset version CDATA #REQUIRED>

<!ELEMENT rule (id, action)>

<!ELEMENT id (certificate?) (checksum?) >
<!ATTRIBUTE id title CDATA #IMPLIED>
<!ATTRIBUTE id location CDATA #IMPLIED>

<!ELEMENT certificate EMPTY>
<!ATTLIST certificate algorithm CDATA #IMPLIED>
<!ATTLIST certificate hash CDATA #REQUIRED>

<!ELEMENT checksum EMPTY>
<!ATTLIST checksum algorithm CDATA #IMPLIED>
<!ATTLIST checksum hash CDATA #REQUIRED>
 
<!ELEMENT action (message?)>
<!ATTRIBUTE permission (run | block | default) #REQUIRED>
<!ATTRIBUTE version CDATA #IMPLIED>
<!ATTRIBUTE force (true|false) "false">

<!ELEMENT message (#PCDATA)>
<!ATTLIST message locale CDATA #IMPLIED>

Java Expiration Date

The expiration date for 8u60 is October 20, 2015. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u60) on November 20, 2015. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

For a list of bug fixes included in this release, see JDK 8u60 Bug Fixes page.

» 8u60 Release notes

Java 8 Update 51 (8u51)

Release Highlights

IANA Data 2015d
JDK 8u51 contains IANA time zone data version 2015d. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Add new Comodo roots to root CAs
Four new root certificates have been added for Commodo:
1. COMODO ECC Certification Authority alias: comodoeccca DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
2. COMODO RSA Certification Authority alias: comodorsaca DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
3. USERTrust ECC Certification Authority alias: usertrusteccca DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
4. USERTrust RSA Certification Authority alias: usertrustrsaca DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
See JDK-8077997 (not public).
Bug Fix: Add new GlobalSign roots to root CAs
Two root certificates have been added for GlobalSign:
1. GlobalSign ECC Root CA - R4 alias: globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
2. GlobalSign ECC Root CA - R5 alias: globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
See JDK-8077995 (not public).
Bug Fix: Add Actalis to root CAs
Added one new root certificate:
Actalis Authentication Root CA alias: actalisauthenticationrootca DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
See JDK-8077903 (not public).
Bug Fix: Add new Entrust ECC root
Added one new root certificate:
Entrust Root Certification Authority - EC1 alias: entrustrootcaec1 DN: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
See JDK-8073286 (not public).
Bug Fix: Remove old Valicert Class 1 and 2 Policy roots
Removed two root certificates with 1024-bit keys:
1. ValiCert Class 1 Policy Validation Authority alias: secomvalicertclass1ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
2. ValiCert Class 2 Policy Validation Authority alias: valicertclass2ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
See JDK-8077886 (not public).
Bug Fix: Remove old Thawte roots
Removed two root certificates with 1024-bit keys:
1. Thawte Server CA alias: thawteserverca DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
2. Thawte Personal Freemail CA alias: thawtepersonalfreemailca DN: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
See JDK-8074423 (not public).
Bug Fix: Remove more old Verisign, Equifax, and Thawte roots
Removed five root certificates with 1024-bit keys:
1. Verisign Class 3 Public Primary Certification Authority - G2 alias: verisignclass3g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
2. Thawte Premium Server CA alias: thawtepremiumserverca DN: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
3. Equifax Secure Certificate Authority alias: equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
4. Equifax Secure eBusiness CA-1 alias: equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
5. Equifax Secure Global eBusiness CA-1, alias: equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
See JDK-8076202 (not public).
Bug Fix: Remove TrustCenter CA roots from cacerts
Removed three root certificates:
1. TC TrustCenter Universal CA I alias: trustcenteruniversalcai DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
2. TC TrustCenter Class 2 CA II alias: trustcenterclass2caii DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
3. TC TrustCenter Class 4 CA II alias: trustcenterclass4caii DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
See JDK-8072958 (not public).
Bug Fix: Deprecate RC4 in SunJSSE provider
RC4 is now considered as a weak cipher. Servers should not select RC4 unless there is no other stronger candidate in the client requested cipher suites. A new security property, jdk.tls.legacyAlgorithms, is added to define the legacy algorithms in Oracle JSSE implementation. RC4 related algorithms are added to the legacy algorithms list. See JDK-8074006 (not public).
Bug Fix: Prohibit RC4 cipher suites
RC4 is now considered as a compromised cipher. RC4 cipher suites have been removed from both client and server default enabled cipher suite list in Oracle JSSE implementation. These cipher suites can still be enabled by SSLEngine.setEnabledCipherSuites() and SSLSocket.setEnabledCipherSuites() methods. See JDK-8077109 (not public).
Bug Fix: Improved certification checking
With this fix, JSSE endpoint identification does not perform reverse name lookup for IP addresses by default in JDK. If an application does need to perform reverse name lookup for raw IP addresses in SSL/TLS connections, and encounter endpoint identification compatibility issue, System property "jdk.tls.trustNameService" can be used to switch on reverse name lookup. Note that if the name service is not trustworthy, enabling reverse name lookup may be susceptible to MITM attacks. See JDK-8067695 (not public).

Java Expiration Date

The expiration date for 8u51 is October 20, 2015. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u51) on November 20, 2015. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u51 Bug Fixes page.

» 8u51 Release notes

Java 8 Update 45 (8u45)

Release Highlights

IANA Data 2015a
JDK 8u45 contains IANA time zone data version 2015a. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Improve jar file handling. Starting with JDK 8u45 release, the jar tool no longer allows the leading slash "/" and ".." (dot-dot) path component in zip entry file name when creating new and/or extracting from zip and jar file. If needed, the new command line option "-P" should be used explicitly to preserve the dot-dot and/or absolute path component. See 8064601 (not public).
Bug Fix: jnlp app with nested "resource" section fails with NPE on load in jre8u40. A jnlp application, with nested tags within a <java> or tag, can throw a NPE. The issue is now fixed. The tag should be used only if the <java> is actually used. See 8072631 (not public).

Java Expiration Date

The expiration date for 8u45 is July 14, 2015. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u45) on August 14, 2015. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u45 Bug Fixes page.

» 8u45 Release notes

Java 8 Update 40 (8u40)

Release Highlights

IANA Data 2014j
JDK 8u40 contains IANA time zone data version 2014j. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Default and static interface methods in JDI, JDWP and JDB. Since JDK 8 it is possible to have directly executable static and default methods in interfaces. These methods are not executable via JDWP or JDI and therefore can not be properly debugged. See JDK 8 Compatibility Guide for more details. See 8042123.
Bug Fix: Java Access Bridge can be enabled from Control panel for 32 bit jres. Previously the "Enable Java Access Bridge" check box got removed from the Java Control Panel with 64 bit jre uninstall even when 32 bit JRE was still present on the system. Starting with JDK 8u40 release, the "Enable Java Access Bridge" checkbox is retained, at Control Panel -> Ease of Access -> Ease of Access Center -> Use the computer without a display, if a 32 bit jre is present. So, a user can enable Java Access bridge via control panel for See 8030124.
Bug Fix: Modernizing the JavaFX Media Stack on Mac OS X. An AVFoundation based player platform is added to JavaFX media. The old QTKit based platform is now removable for Mac App Store compatibility. See 8043697 (not public)
Bug Fix: Missing DOM APIs. In JDK 8u40 release, the old plugin DOM APIs were inadvertently removed. If an applet requires the use of com.sun.java.browser.dom.DOMService to communicate with the browser, then users may need to update their applet to use netscape.javascript.JSObject or continue using JDK 8 Update 31. This issue has been resolved in build 26 and new 8u40 installers have been posted. If you are experiencing this problem please download and run the updated JDK 8u40 installers. See 8074564.
Bug Fix: Mac 10.10: Application run with splash screen has focus issues. Applications started through webstart or standalone applications, which use splash screen, cannot get keyboard focus. Workaround: Launch javaws using the -Xnosplash option. This issue has been resolved in build 27 and a new 8u40 installer has been posted. If you are experiencing this problem, download and run the updated JDK 8u40 installer. See 8074668.
Java Packager Tool Enhancements
JDK 8u40 release contains the following enhancements to the Java Packager:
- Command-line arguments can be passed to self-contained applications. Default arguments are defined when the package is created, which can be overridden by the user when the application is started.
- File associations can be set up when a self-contained application is installed so that the operating system automatically runs the application for registered file extensions or MIME types.
- The UserJvmOptionsService API is available for altering JVM options in self-contained applications. The new settings are used the next time the application is started.
- Multiple entry points are supported for self-contained applications which enables a suite of products to be bundled into the same application package.
Deprecated APIs
The endorsed-standards override mechanism and the extension mechanism are deprecated and may be removed in a future release. There are no runtime changes. Existing applications using the 'endorsed-standards override' or 'extension' mechanisms are recommended to migrate away from using these mechanisms. To help identify any existing uses of these mechanisms, the -XX:+CheckEndorsedAndExtDirs command-line option is available. It will fail if any of the following conditions is true:
- -Djava.endorsed.dirs or -Djava.ext.dirs system property is set to alter the default location; or
- ${java.home}/lib/endorsed directory exists; or
- ${java.home}/lib/ext contains any JAR files excluding the ones that JDK ships or
- any platform-specific system-wide extension directory contains any JAR files.
The -XX:+CheckEndorsedAndExtDirs command-line option is supported in JDK 8u40 and later releases.
JJS Tool Page Differences
The Japanese version of the jjs help page is different from the English version. Some of the unsupported options have been removed from the English version of the jjs tool page. The Japanese version of document will be updated in future. See 8062100 (not public). For other jjs tool page changes, see Tools Enhancements in JDK 8.
Change in default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent
The default value for G1HeapWastePercent was changed from 10 to 5 to reduce the need for full GCs. For the same reason the default value for G1MixedGCLiveThresholdPercent was changed from 65 to 85.
New Java class-access Filtering Interface
The jdk.nashorn.api.scripting.ClassFilter interface enables you to restrict access to specified Java classes from scripts run by a Nashorn script engine. See Restricting Script Access to Specified Java Classes in the Nashorn User's Guide and 8043717 (not public) for more information.
Issues with Third party's JCE providers
The fix for JDK-8023069 (in JDK 8u20) updated both the SunJSSE and and SunJCE providers, including some internal interfaces. Some third party JCE providers (such as RSA JSAFE) are using some sun.* internal interfaces, and therefore will not work with the updated SunJSSE provider. Such providers will need to be updated in order for them to work with the updated SunJSSE provider. If you have been impacted by this issue, please contact your JCE vendor for an update. See 8058731.
Re-enabled encryptions in Solaris Crypto Framework
If you are using Solaris 10, a change was made to re-enable operations with MD5, SHA1, and SHA2 through the Solaris Crypto Framework. If you experience a CloneNotSupportedException or PKCS11 error CKR_SAVED_STATE_INVALID message with JDK 8u40, you should verify and apply the below patches or newer version of them:
- 150531-02 on sparc
- 150636-01 on x86
Troubleshooting Guide Updates for NMT
The Native Memory Tracking (NMT) is a Java Hotspot VM feature that tracks internal memory usage for a HotSpot JVM. Native Memory Tracking can be used to monitor VM internal memory allocations and diagnose VM memory leaks. VM enhancements page is updated with NMT features. See Java Virtual Machine Enhancements in Java SE 8. Troubleshooting Guide is updated with NMT features. See Native Memory Tracking.
Multiple JRE Launcher feature deprecated
The Launch-Time JRE Version Selection or the Multiple JRE Launcher feature is deprecated in JDK 8u40. Applications that require specific Java versions deployed using this feature must switch to alternate deployment solutions such as Java WebStart.
JavaFX Enhancements
Starting with JDK 8u40 release, JavaFX controls are enhanced to support assistive technologies, meaning that JavaFX controls are now accessible. In addition, a public API is provided to allow developers to write their own accessible controls. Accessibility support is provided on Windows and Mac OS X platforms and includes:
- Support for reading JavaFX controls by a screen reader
- JavaFX controls are traversable using the keyboard
- Support for a special high-contrast mode that makes controls more visible to users.
See 8043344 (not public).

JDK 8u40 release includes new JavaFX UI controls; a spinner control, formatted-text support, and a standard set of alert dialogs.
- Spinner Control: A Spinner is a single line text field that lets the user select a number or an object value from an ordered sequence. See javafx.scene.control.Spinner class for more information.
- Formatted Text: A new TextFormatter class provides text formatting capablity for subclasses of TextInputControl (for example, TextField and TextArea). See javafx.scene.control.TextFormatter class for more information.
- Dialogs: The Dialog class allows applications to create their own custom dialogs. In addition, an an Alert class is also provided, that extends Dialog, and provides support for a number of pre-built dialog types that can be easily shown to users to prompt for a response. See javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog, javafx.scene.control.ChoiceDialog classes for more information.
See 8043350 (not public).

Commercial Features

Application Class Data Sharing (AppCDS)
Application Class Data Sharing (AppCDS) extends CDS to enable you to place classes from the standard extensions directories and the application class path in the shared archive. This is an experimental feature and not licensed for commercial use. See the -XX:+UseAppCDS option in the java launcher tool page.
Cooperative Memory Management
Starting with JDK 8u40, the notion of "memory pressure" has been added to the JDK. Memory pressure is a property that represents the total memory usage (RAM) on the system. The higher the memory pressure, the closer the system is to running out of memory. This is an experimental feature and not licensed for commercial use. As a reaction to increased memory pressure, the JDK will try to reduce its memory usage. This is mainly done by reducing the Java heap size. The actions the JDK will take to reduce memory usage may lead to reduced performance. This is an intentional choice. The pressure level is provided by the application through a JMX MXBean using a scale from 0 (no pressure) to 10 (almost out of memory). To enable this feature, the jdk.management.cmm.SystemResourcePressureMXBean should be registered. The memory pressure is then set using the "MemoryPressure" attribute.
A new command line flag -XX:MemoryRestriction that takes one of the arguments 'none', 'low', 'medium', or 'high', is also available. This flag will set the initial pressure in the JDK and will work also in cases where the MXBean is not registered. Cooperative Memory Management requires the G1 GC (-XX:+UseG1GC). This feature is not compatible with the flag -XX:+ExplicitGCInvokesConcurrent.
New commercial flags
Two new VM options are now available for commercial license holders:
- -XX:+ResourceManagement
- -XX:ResourceManagementSampleInterval=value (milliseconds)
For more information, see Java Launcher documentation.
New MSI Installer Documentation:
The Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide is available. The MSI Enterprise JRE Installer requires a commercial license for use in production. Learn more about commercial features and how to enable them.

Java Expiration Date

The expiration date for 8u40 is April 14, 2015. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u40) on May 14, 2015. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

For a list of bug fixes included in this release, see JDK 8u40 Bug Fixes page.

» 8u40 Release notes

Java 8 Update 31 (8u31)

Release Highlights

IANA Data 2014j
JDK 8u31 contains IANA time zone data version 2014j. For more information, refer to Timezone Data Versions in the JRE Software.
SSLv3 is disabled by default
Starting with JDK 8u31 release, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not normally available. Please see the jdk.tls.disabledAlgorithms property in \lib\security\java.security file. If SSLv3 is absolutely required, the protocol can be reactivated by removing 'SSLv3' from the jdk.tls.disabledAlgorithms property in the java.security file or by dynamically setting this security property before JSSE is initialized.
Changes to Java Control Panel
Starting with JDK 8u31 release, SSLv3 protocol is removed from Java Control Panel Advanced options. If the user needs to use SSLv3 for applications, re-enable it manually as follows:
- Enable SSLv3 protocol on JRE level: as described in the previous section.
- Enable SSLv3 protocol on deploy level: edit the deployment.properties file and add the following:
  
  deployment.security.SSLv3=true

Java Expiration Date

The expiration date for 8u31 is April 14, 2015. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u31) on May 14, 2015. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u31 Bug Fixes page.

» 8u31 Release notes

Java 8 Update 25 (8u25)

Release Highlights

IANA Data 2014c
JDK 8u25 contains IANA time zone data version 2014c. For more information, refer to Timezone Data Versions in the JRE Software.
Bug Fix: Decrease the preference mode of RC4 in the enabled cipher suite list
This fix decreases the preference of RC4 based cipher suites in the default enabled cipher suite list of SunJSSE provider. See 8043200 (not public).
Bug Fix: JRE 8u20 crashes while using Japanese IM on Windows
The VM crashes while using Swing controls when some Japanese or Chinese characters are input on Windows platform. The issue is now fixed. See 8058858 (not public).

Instructions to disable SSL v3.0 in Oracle JDK and JRE

Oracle recommends that users and developers disable use of the SSLv3 protocol.
» How can Java users confirm they are not affected by the SSL V3.0 'Poodle' vulnerability?

Java Expiration Date

The expiration date for 8u25 is January 20, 2015. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u25) on February 20, 2015. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u25 Bug Fixes page.

» 8u25 Release notes

Java 8 Update 20 (8u20)

Release Highlights

New flags added to Java Management API
The flags MinHeapFreeRatio and MaxHeapFreeRatio have been made manageable. This means they can be changed at runtime using the management API in Java. Support for these flags have also been added to the ParallelGC as part of the adaptive size policy.
Java Installer Changes
- A new Microsoft Windows Installer (MSI) Enterprise JRE Installer which enables user to install the JRE across the enterprise, is available. See Downloading the Installer section in JRE Installation for Microsoft Windows for more information. The MSI Enterprise JRE Installer is only available as part of Java SE Advanced or Java SE Suite. For information about these commercial products, see Java SE Advanced and Java SE Suite.
- The Java Uninstall Tool is integrated with the installer to provide an option to remove older versions of Java from the system. The change is applicable to 32 bit and 64 bit Windows platforms. See Uninstalling the JRE.
Java Control Panel Changes
- The Update tab in the Java Control Panel now enables the users to automatically update 64-bit JREs (in addition to 32-bit versions) that are installed on their system.
- The Medium security level has been removed. Now only High and Very High levels are available. Applets that do not conform with the latest security practices can still be authorized to run by including the sites that host them to the Exception Site List. The exception site list provides users with the option of allowing the same applets that would have been allowed by selecting the Medium option but on a site-by-site basis therefore minimizing the risk of the using more permissive settings.
Java Compiler updated
The javac compiler has been updated to implement definite assignment analysis for blank final field access using "this". See JDK 8 Compatibility Guide for more details.
Change in minimum required Java Version for Java Plugin and Java Webstart
The minimum version of Java required for Java Plugin and Java Webstart is now Java 5. Applets that do not run in Java 5 or later must be ported to a later version of Java to continue to function. Applets written for earlier versions but able to run in at least Java 5 will continue to work.
Change in UsageTracker output formatting
UsageTracker output formatting has been changed to use quoting, to avoid confusion in the log. This may require changes to the way such information is read. The feature can be configured to behave as in previous versions, although the new format is recommended. See Java Usage Tracker documentation.
Changes to Java Packaging Tools
- javafxpackager has been renamed to javapackager
- The "-B" option has been added to the javapackager deploy command to enable you to pass arguments to the bundlers that are used to create self-contained applications. See javapackager (Windows)/(Unix) documentation for information
- The helper parameter argument has been added to JavaFX Ant Task Reference. It enables you to specify an argument (in the element) for the bundler that is used to create self-contained applications.

Java Expiration Date

The expiration date for 8u20 is October 14, 2014. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u20) on November 14, 2014. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

For a list of bug fixes included in this release, see JDK 8u20 Bug Fixes page.

» 8u20 Release notes

Java 8 Update 11 (8u11)

This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u11 Bug Fixes page.

» 8u11 Release notes

Java 8 Update 5 (8u5)

This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 8u5 Bug Fixes page.

» 8u5 Release notes

Java 8 Release

» JDK and JRE 8 Release notes

You might also be interested in:

Java 7 and Java 8 Releases by Date

Help Resources

Find expert help on Java installation and setup