Java 8 release changes

Help Resources

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 441 (8u441)

Release Highlights

JDK 8u441 contains IANA time zone data 2024b .
For more information, refer to Timezone Data Versions in the JRE Software.
JavaFX Will No Longer Be Included in JDK/JRE 8
This release, JDK and JRE 8 update 441, is the last release to bundle JavaFX. As announced in 2020, support for JavaFX on JDK 8, the last commercially supported version of JavaFX from Oracle, will end in March 2025. Accordingly, JDK 8 update 441 is the last upgrade of JDK/JRE 8 with JavaFX. Oracle continues to develop and release JavaFX as stand-alone modules via the OpenJFX project for the latest versions of Java only. For more details see the Java SE Spring 2024 Roadmap Update.
Other Notes: Support for Time Zone Database 2024b
IANA Time Zone Database has been upgraded to 2024b. This version mainly includes changes to improve historical data for Mexico, Mongolia, and Portugal. It also changes one timestamp abbreviation, for the time zone 'MET'. Also Asia/Choibalsan is now an alias for Asia/Ulaanbaatar.
See JDK-8339637

Keeping the JDK up to Date

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u441) be used after the next critical patch update scheduled for April 15, 2025.

Java Management Service, available to all users, can help you find vulnerable Java versions in your systems. Java SE Subscribers and customers running in Oracle Cloud can use Java Management Service to update Java Runtimes and to do further security reviews like identifying potentially vulnerable third party libraries used by your Java programs. Existing Java Management Service user click here to log in to your dashboard. The Java Management Service Documentation provides a list of features available to everyone and those available only to customers. Learn more about using Java Management Service to monitor and secure your Java Installations.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u441) on 2025-05-15. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see 8u441 Release notes.

Java 8 Update 431 (8u431)

Release Highlights

JDK 8u431 contains IANA time zone data 2024a .
For more information, refer to Timezone Data Versions in the JRE Software.
Notable Issues Resolved: JDK RPM Upgrade Leaves Orphan Alternatives Entry
Fixed the issue with entries in the "java" and "javac" groups not being properly managed during an RPM upgrade.
Upgrading from an older Java RPM installed into a shared directory (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) to a Java RPM installing into a version-specific directory (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), results in the older Java entries in the "java" and "javac" groups not being deleted.
JDK-8336107 (not public)
Other Notes: New Default Limits in the JDK HTTP Implementations
New, default limits have been added to HTTP in the JDK.
The JDK built-in implementation of the URL protocol handler for HTTP (HttpURLConnection) now has a default limit on the maximum response headers size that will be accepted from a remote party. The limit is set by default at 384kB (393216 bytes) and is computed as the cumulative size of all header names and header values plus an overhead of 32 bytes per header name value pair.
JDK-8328286 (not public)
Other Notes: Added SSL.com TLS Root CA Certificates Issued in 2022
The following root certificates have been added to the cacerts truststore:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
See JDK-8341057
Other Notes: Distrust TLS Server Certificates Anchored by Entrust Root Certificates and Issued After Nov 11, 2024
The JDK will stop trusting TLS server certificates issued after November 11, 2024 and anchored by Entrust root certificates, in line with similar plans recently announced by Google and Mozilla. The list of affected certificates includes certificates branded as AffirmTrust, which are managed by Entrust.
See JDK-8337664

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u431) be used after the next critical patch update scheduled for January 21, 2025.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u431) on 2025-02-21. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 421 (8u421)

Release Highlights

JDK 8u421 contains IANA time zone data 2024a .
For more information, refer to Timezone Data Versions in the JRE Software.
Known Issue: Browser Keystore Usage on Windows
On Windows, once the feature “Use certificates and keys in browser keystore” is enabled (which it is by default), Java WebStart and Java Plugin can access the certificates that are currently trusted by the local machine. There is no guarantee that the full list of trusted certificates is available, since the certificates are dynamically loaded. As a result, Java applets and Java WebStart applications might experience signature validation and secure connection issues caused by a lack of relevant certificates since the Deployment framework can only access the certificates that are 'active' at the time of an application's launch.
JDK-8330728 (not public)
Other Notes: Adding the STATIC=1 Argument to the JRE Installer
This fix will add the STATIC=1 installer argument and deprecating the RETAIN_ALL_VERSIONS=1 installer argument. Passing STATIC=1 will protect older JRE 8 versions from being uninstalled during a manual upgrade or an auto-update.
JDK-8313223 (not public)
Other Notes: Added GlobalSign R46 and E46 Root CA Certificates
The following root certificates have been added to the cacerts truststore:
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
See JDK-8316138
Other Notes: Installer Will Create a Junction Directory in a New Location
The JRE will be installed in the following location, C:\Program Files\Java\latest\jre-$fullversion, where $fullversion is the technical version of the JRE. For instance, 8u421 will install into C:\Program Files\Java\latest\jre-1.8.0_421.

"C:\Program Files" will be adjusted to "C:\Program Files (x86)" for 32-bit Java.

A junction will be created at C:\Program Files\Java\latest\jre-1.8. It will point to the latest JRE of the 8 family.
JDK-8329700 (not public)

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u421) be used after the next critical patch update scheduled for October 15, 2024.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u421) on 2024-11-15. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 411 (8u411)

Release Highlights

JDK 8u411 contains IANA time zone data 2024a .
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Added Certainly R1 and E1 Root Certificates
The following root certificates have been added to the cacerts truststore:+ Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
See JDK-8321408
New Feature: Enable XML Signature Secure Validation Mode by Default
The XML Signature secure validation mode has been enabled by default (previously it was not enabled by default unless running with a security manager). When enabled, validation of XML signatures are subject to stricter checking of algorithms and other constraints as specified by the jdk.xml.dsig.secureValidationPolicy security property.
If necessary, and at their own risk, applications can disable the mode by setting the org.jcp.xml.dsig.secureValidation property to Boolean.FALSE with the DOMValidateContext.setProperty() API.
See JDK-8259801

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u411) be used after the next critical patch update scheduled for July 16, 2024.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u411) on 2024-08-16. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 401 (8u401)

Release Highlights

JDK 8u401 contains IANA time zone data 2023c.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: New System Property to Toggle XML Signature Secure Validation Mode
A new system property named org.jcp.xml.dsig.secureValidation has been added. It can be used to enable or disable the XML Signature secure validation mode. The system property should be set to "true" to enable, or "false" to disable. Any other value for the system property is treated as "false". If the system property is set, it supersedes the XMLCryptoContext property value. Secure validation mode is enabled by default if you are running the code with a SecurityManager, otherwise it is disabled by default.
See JDK-8301260
New Feature: JDK Flight Recorder Event for Deserialization
A new JDK Flight Recorder (JFR) event has been added to monitor deserialization of objects. When JFR is enabled and the JFR configuration includes deserialization events, JFR will emit an event whenever the running program attempts to deserialize an object. The deserialization event is named java/deserialization, and it is disabled by default. The deserialization event contains information that is used by the serialization filter mechanism. Additionally, if a filter is enabled, the JFR event indicates whether the filter accepted or rejected deserialization of the object.
See JDK-8261160

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u401) be used after the next critical patch update scheduled for April 16, 2024.

Java SE Subscription products customers managing JRE updates/installs for large number of desktops should consider using Java Management Service (JMS).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u401) on 2024-05-16. After either condition is met (new release becoming available or expiration date reached),the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 391 (8u391)

Release Highlights

JDK 8u391 contains IANA time zone data 2023c.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: New JFR Event: jdk.SecurityProviderService
A new Java Flight Recorder (JFR) event has been added to record details of java.security.Provider.getService(String type, String algorithm) calls.
See JDK-8254711
Removed Feature: Removed SECOM Trust System's RootCA1 Root Certificate
The following root certificate from SECOM Trust System has been removed from the cacerts keystore:
+ alias name "secomscrootca1 [jdk]" Distinguished Name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
See JDK-8295894
Removed Feature: Removal of Linux ARM32 Support for JDK 8
Platform support for Linux ARM32 in JDK 8 has been removed. As a result, the ARM32 Hard Float ABI download will not be available. Operating Systems that supported ARM32 have reached their End of Life, thus there is no known OS support available.
JDK-8305927 (not public)
Other Notes: Added Certigna Root CA Certificate
The following root certificate has been added to the cacerts truststore:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
See JDK-8314960

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u391) be used after the next critical patch update scheduled for January 16, 2024.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u391) on 2024-02-16. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version.For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 381 (8u381)

Release Highlights

JDK 8u381 contains IANA time zone data 2023c.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Allow Additional Characters for GB18030-2022 Support
The China National Standard body (CESI) has recently published GB18030-2022, which is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The Charset implementation for this new standard has now replaced the prior 2000 standard. However, this new standard has some incompatible changes from the prior implementation. For those who need to use the old mappings, a new system property, jdk.charset.GB18030, is introduced. By setting its value to 2000, the previous JDK releases' mappings for the GB18030 Charset are used, which are based on the 2000 standard.
See JDK-8307229
JDK Now Accepts RSA Keys in PKCS#1 Format
RSA private and public keys in PKCS#1 format can now be accepted by JDK providers, such as the RSA KeyFactory.impl from the SunRsaSign provider. The RSA private or public key object should have the PKCS#1 format and an encoding matching the ASN.1 syntax for a PKCS#1 RSA private key and public key.
See JDK-8023980
Other Notes: Cgroup v2 Support and Improvements in 8u381
JDK 8u381 includes several enhancements and fixes to improve the cgroup v1 and v2 support for containers. The improvements include accurately detecting the resource limits of containers, correctly reporting the collected container metrics, printing additional container information, and improving application stability in containerized environments.
See JDK-8307634
Other Notes: Added TWCA Root CA Certificate
The following root certificate has been added to the cacerts truststore:
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
See JDK-8305975
Other Notes: Added 4 GTS Root CA Certificates
The following root certificates have been added to the cacerts truststore:
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
See JDK-8307134
Other Notes: Added Microsoft Corporation's 2 TLS Root CA Certificates
The following root certificates have been added to the cacerts truststore:
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
See JDK-8304760

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u381) be used after the next critical patch update scheduled for October 17, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u381) on 2023-11-17. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 371 (8u371)

Release Highlights

JDK 8u371 contains IANA time zone data 2022g.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Added a Default Native GSS-API Library on Windows
A native GSS-API library has been added to JDK on the Windows platform. The library is client-side only and uses the default credentials. It will be loaded when the sun.security.jgss.native system property is set to "true". A user can still load a third-party native GSS-API library by setting the system property sun.security.jgss.lib to its path.
See JDK-6722928
Removed Features and Options: javax.script Engine Implementation and com.apple.concurrent.Dispatch Are Removed for macOS AArch64
The AppleScript engine implementing the javax.script engine API has been removed without replacement. The AppleScript engine has worked inconsistently. The services configuration (META-INF/services) file was missing and only worked by accident when installing JDK 7 or JDK 8 on systems that had Apple's version of AppleScriptEngine.jar already on the system.
The com.apple.concurrent.Dispatch API was a Mac-only API. It was carried into JDK 7u4 with the port of Apple's JDK 6 code. Developers are encouraged to use the standard java.util.concurrent.Executor and java.util.concurrent.ExecutorService APIs instead.
See JDK-8297475
Other Notes: Added Certigna(Dhimyotis) Root CA Certificate
The following root certificate has been added to the cacerts truststore:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
See JDK-8245654
Other Notes: Removed SSLv2Hello and SSLv3 From Default Enabled TLS Protocols
SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.

After this update, if SSLv3 is removed from the jdk.tls.disabledAlgorithms security property, the SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() and SSLParameters.getProtocols() APIs will return "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.
If a client or server still needs to use the SSLv3 protocol they can do so by enabling it through the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs.
See JDK-8190492

Keeping the JDK up to Date

Oracle recommends that the JDK is updated with each Critical Patch Update. Use the Security Baseline page to determine the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended to use this JDK (version 8u371) after the next critical patch update release, scheduled for July 18, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u371) on 2023-08-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 361 (8u361)

Release Highlights

JDK 8u361 contains IANA time zone data 2022d, 2022e, 2022f.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Support for RSASSA-PSS in OCSP Response
An OCSP response signed with the RSASSA-PSS algorithm is now supported.
See JDK-8274471
Other Notes: FXML JavaScript Engine Disabled by Default
The “JavaScript script engine” for FXML is now disabled by default. Any .fxml file that has a "javascript" Processing Instruction (PI) will no longer load by default, and an exception will be thrown.
It can be enabled by setting the system property: -Djavafx.allowjs=true
JDK-8294779 (not public)
Other Notes: Incorrect Handling of Quoted Arguments in ProcessBuilder
ProcessBuilder on Windows is restored to address a regression caused by JDK-8250568. Previously, an argument to ProcessBuilder that started with a double-quote and ended with a backslash followed by a double-quote was passed to a command incorrectly and may cause the command to fail. For example the argument "C:\\Program Files\", would be seen by the command with extra double-quotes. This update restores the long standing behavior that does not treat the backslash before the final double-quote specially.
See JDK-8282008
Other Notes: Make HttpURLConnection Default Keep Alive Timeout Configurable
Two system properties have been added which control the keep alive behavior of HttpURLConnection in the case where the server does not specify a keep alive time. Two properties are defined for controlling connections to servers and proxies separately. They are http.keepAlive.time.server and http.keepAlive.time.proxy respectively. More information about them can be found in Networking Properties.
See JDK-8278067
Other Notes:VisualVM tool no longer bundled
This version of the JDK no longer includes a copy of Java VisualVM. VisualVM is now available as a separate download from https://visualvm.github.io.
See JDK-8294184

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u361) be used after the next critical patch update scheduled for April 18, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u361) on 2023-05-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

Java 8 Update 351 (8u351)

Release Highlights

IANA TZ Data 2022b, 2022c..
For more information, refer to Timezone Data Versions in the JRE Software.
Other Notes: Upgrade the default PKCS12 MAC algorithm
The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
See JDK-8267880
Other Notes: Disabled SHA-1 Signed JARs
JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. These restrictions also apply to signed JCE providers.
See JDK-8269039
Other Notes: Deprecate 3DES and RC4 in Kerberos
The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.
See JDK-8139348

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u351) be used after the next critical patch update scheduled for January 17, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u351) on 2023-02-17. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u351 Release notes

Java 8 Update 341 (8u341)

Release Highlights

IANA TZ Data 2022a.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: HTTPS Channel Binding Support for Java GSS/Kerberos
Support has been added for TLS channel binding tokens for Negotiate/Kerberos authentication over HTTPS through javax.net.HttpsURLConnection.

Channel binding tokens are increasingly required as an enhanced form of security. They work by communicating from a client to a server the client's understanding of the binding between connection security (as represented by a TLS server cert) and higher level authentication credentials (such as a username and password). The server can then detect if the client has been fooled by a MITM and shutdown the session/connection.
See JDK-8279842
New Feature: Enable TLSv1.3 by Default on JDK 8u for Client Roles
The TLSv1.3 implementation is available in JDK 8u from 8u261 and enabled by default for server roles but disabled by default for client roles. From this release onwards, TLSv1.3 is now also enabled by default for client roles. You can find more details in the Additional Information section of the Oracle JRE and JDK Cryptographic Roadmap.
See JDK-8245263
Other Notes:Update java.net.InetAddress to Detect Ambiguous IPv4 Address Literals
The java.net.InetAddress class has been updated to strictly accept IPv4 address literals in decimal quad notation. The InetAddress class methods are updated to throw an java.net.UnknownHostException for invalid IPv4 address literals. To disable this check, the new "jdk.net.allowAmbiguousIPAddressLiterals" system property can be set to "true".
See JDK-8277608 (not public)
Other Notes:JDK Bundle Extensions Truncated When Downloading Using Firefox 102
On oracle.com and java.com, certain JDK bundle extensions are getting truncated on download when using Firefox version 102. The downloaded bundles have no file extension like ".exe", ".rpm", ".deb". If you are not able to upgrade to Firefox ESR 102.0.1 or Firefox 103 when it is released, then as a workaround you can:
‐manually add a file extension to the file name after download.
‐use a different browser
See JDK-8277093

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u341) be used after the next critical patch update scheduled for October 18, 2022.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u341) on 2022-11-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u341 Release notes

Java 8 Update 333 (8u333)

Release Highlights

IANA TZ Data 2021a.
For more information, refer to Timezone Data Versions in the JRE Software.
Change: Enable Windows Alternate Data Streams by default
The Windows implementation of java.io.File has been changed so that strict validity checks are not performed by default on file paths. This includes allowing colons (‘:’) in the path other than only immediately after a single drive letter. It also allows paths that represent NTFS Alternate Data Streams (ADS), such as “filename:streamname”. This restores the default behavior of java.io.File to what it was prior to the April 2022 CPU in which strict validity checks were not performed by default on file paths on Windows. To re-enable strict path checking in java.io.File, the system property jdk.io.File.enableADS should be set to false (case ignored). This might be preferable, for example, if Windows special device paths such as NUL: are not used.
See JDK-8285445

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u333) be used after the next critical patch update scheduled for July 19, 2022.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u333) on 2022-08-19. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

This release is based on the previous CPU and does not contain any additional security fixes. For a more complete list of the bug fixes included in this release, see the JDK 8u333 Release notes page.

» 8u333 Release notes

Java 8 Update 331 (8u331)

Release Highlights

IANA TZ Data 2021e.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: New XML Processing Limits
Three processing limits have been added. These are:
- jdk.xml.xpathExprGrpLimit
  Description: Limits the number of groups an XPath expression can contain.
  Type: integer
  Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10.
- jdk.xml.xpathExprOpLimit
  Description: Limits the number of operators an XPath expression can contain.
  Type: integer
  Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 100.
- jdk.xml.xpathTotalOpLimit
  Description: Limits the total number of XPath operators in an XSL Stylesheet.
  Type: integer
  Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10000.
Supported processors
- jdk.xml.xpathExprGrpLimit and jdk.xml.xpathExprOpLimit are supported by the XPath processor.
- All three limits are supported by the XSLT processor.
Setting properties
For the XSLT processor, the properties can be changed through the TransformerFactory. For example,
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
For both the XPath and XSLT processors, the properties can be set through the system property and jaxp.properties configuration file located in the conf directory of the Java installation. For example,
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
or in the jaxp.properties file,
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (not public)
Other notes: Only Expose Certificates With Proper Trust Settings as Trusted Certificate Entries in macOS KeychainStore
On macOS, only certificates with proper trust settings in the user keychain will be exposed as trusted certificate entries in the KeychainStore type of keystore. Also, calling the KeyStore::setCertificateEntry method or the keytool -importcert command on a KeychainStore keystore now fails with a KeyStoreException. Instead, call the macOS "security add-trusted-cert" command to add a trusted certificate into the user keychain.
JDK-8278449 (not public)
Other notes: The parsing of URLs in the LDAP, DNS, RMI and CORBA built-in JNDI providers as been made more strict. The strength of the parsing can be controlled by system properties:
The parsing of URLs in the LDAP, DNS, and RMI built-in JNDI providers as been made more strict. The strength of the parsing can be controlled by system properties:
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict" (to control "dns:" URLs)

  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict" (to control "rmi:" URLs)

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
The default value is "compat" for all of them.
- The "legacy" mode turns the new validation off.
- The "compat" mode limits incompatibilities.
- The "strict" mode is stricter and may cause regression by rejecting URLs that an application might consider as valid.
If an illegal URL string is found, a javax.naming.NamingException (or a subclass of it) is raised.
JDK-8278972 (not public)

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u331) be used after the next critical patch update scheduled for July 19, 2022.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u331) on 2022-08-19. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u331 Release notes

Java 8 Update 321 (8u321)

Release Highlights

IANA TZ Data 2021b, 2021c, 2021d, 2021e.
JDK 8u321 contains IANA time zone data 2021b, 2021c, 2021d, 2021e. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: New SunPKCS11 Configuration Properties
SunPKCS11 provider adds new provider configuration attributes to better control native resources usage. The SunPKCS11 provider consumes native resources in order to work with native PKCS11 libraries. To manage and better control the native resources, additional configuration attributes are added to control the frequency of clearing native references as well as whether to destroy the underlying PKCS11 Token after logout.
See JDK-8240256
Removed Features and Options: Removed Google's GlobalSign Root Certificate
The following root certificate from Google has been removed from the cacerts keystore:
+ alias name "globalsignr2ca [jdk]" Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
See JDK-8225083
Other notes: Update Timezone Data to 2021c
IANA Time Zone Database, on which JDK's Date/Time libraries are based, has made a tweak to some time zone rules since 2021c. Note that since this update, some of the time zone rules prior to the year 1970 have been modified according to the changes which were introduced with 2021b. For more detail, refer to the announcement of 2021b
See JDK-8274407

Keeping the JDK up to Date

Oracle recommends that the JDK is updated with each Critical Patch Update (CPU). In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u291) be used after the next critical patch update scheduled for July 20, 2021.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u291) on 2021-08-20. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u321 Release notes

Java 8 Update 311 (8u311)

Release Highlights

IANA TZ Data 2021a.
For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Marlin Renderer in JDK 8u
Starting from version 8u311, the Marlin graphics rasterizer and its artifacts will be built and distributed as a part of the JDK/JRE bundles. It is not the default rendering engine, however there is an option to enable it by setting the following system property:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
See JDK-8143849
New Feature: Context-specific Deserialization Filter Subset
Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each deserialization stream. The behavior is a strict subset of JEP 415: Context-Specific Deserialization Filters to allow a filter factory to be configured using a property configured on the command line or in the security properties file.
Refer to Context-Specific Deserialization Filter and Serialization Filtering Guide for details.
JDK-8268680 (not public)
Removed Features and Options: Removed IdenTrust Root Certificate
The following root certificate from IdenTrust has been removed from the cacerts keystore:
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
See JDK-8225082
Other notes: Release Doesn't Correctly Recognize Windows 11
This release doesn't correctly identify Windows 11. The property os.name is set to Windows 10 on Windows 11. In HotSpot error logs, the OS is identified as Windows 10; however, the HotSpot error log does show the Build number. Windows 11 has Build 22000.194 or above.
See JDK-8274840
Other notes: Updated the Default Enabled Cipher Suites Preference
The default priority order of the cipher suites for TLS 1.0 to TLS 1.3 has been adjusted.
For TLS 1.3, TLS_AES_256_GCM_SHA384 is now preferred over TLS_AES_128_GCM_SHA256.
For TLS 1.0 to TLS 1.2, some of the intermediate suites have been lowered in priority as follows:
- Cipher suites that do not preserve forward secrecy have been moved lower in priority than those that do support forward secrecy.
- Cipher suites that use SHA-1 have been moved lower in priority.
See JDK-8163326
Other notes: Modified HttpURLConnection Behavior When a Suitable Proxy Is Not Found
The behavior of HttpURLConnection when using ProxySelector has been modified in this JDK release. HttpURLConnection used to fall back to a direct connection attempt if the configured proxy(s) failed to make a connection. Beginning with this release, the default behavior has been changed to no longer use a direct connection when the first proxy connection attempt fails.
See JDK-8161016

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u311) be used after the next critical patch update scheduled for January 18, 2022.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u311) on 2022-02-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u311 Release notes

Java 8 Update 301 (8u301)

Release Highlights

IANA TZ Data 2021a.
JDK 8u301 contains IANA time zone data 2021a. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Customizing PKCS12 keystore Generation
New system and security properties have been added to enable users to customize the generation of PKCS #12 keystores. This includes algorithms and parameters for key protection, certificate protection, and MacData. The detailed explanation and possible values for these properties can be found in the "PKCS12 KeyStore properties" section of the java.security file.
See JDK-8076190
Removed Features and Options: Removed Root Certificates with 1024-bit Keys
Root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore.
See JDK-8243559
Removed Features and Options: Removed Telia Company's Sonera Class2 CA certificate
The following root certificate has been removed from the cacerts truststore:
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
See JDK-8225081
Other notes: Upgraded the Default PKCS12 Encryption Algorithms
The default encryption algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
For compatibility, a new system property namedkeystore.pkcs12.legacy is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.
See JDK-8153005

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u301) be used after the next critical patch update scheduled for October 19, 2021.

Java SE Subscription customers managing JRE updates/installs for large numbers of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u301) on 2021-11-19. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u301 Release notes

Java 8 Update 291 (8u291)

Release Highlights

IANA TZ Data 2020e, 2020f, 2021a.
JDK 8u291 contains IANA time zone data 2020e, 2020f, 2021a. For more information, refer to Timezone Data Versions in the JRE Software.
Other notes: New System and Security Properties to Control Reconstruction of Remote Objects by JDK's Built-in JNDI RMI and LDAP Implementations
jdk.jndi.object.factoriesFilter: This system and security property allows a serial filter to be specified that controls the set of object factory classes permitted to instantiate objects from object references returned by naming/directory systems. The factory class named by the reference instance is matched against this filter during remote reference reconstruction. The filter property supports pattern-based filter syntax with the format specified by JEP 290. This property applies both to the JNDI/RMI and the JNDI/LDAP built-in provider implementations. The default value allows any object factory class specified in the reference to recreate the referenced object.
JDK-8244473 (not public)
Other notes: Default java Version Is Not Updated for Double Click jar Execution
If the PATH environment variable contains a record configured by Oracle JDK installers from newer releases, the Oracle JRE installer inserts the path to the directory containing the Java commands (java.exe, javaw.exe, and javaws.exe) in the PATH environment variable after that record. Previously, the Oracle JRE installer ignored changes made to the PATH environment variable by Oracle JDK installers from newer releases and incorrectly updated the value of PATH environment variable. Please see the following CSR for additional technical information: https://bugs.openjdk.java.net/browse/JDK-8259858
See JDK-8259215
Other notes: Disable TLS 1.0 and 1.1
TLS 1.0 and 1.1 are versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3).
These versions have now been disabled by default. If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.
See JDK-8202343
Other notes: Disable TLS 1.0 and 1.1 for Java Plugin Applets and Java Web Start Applications
TLS 1.0 and 1.1 have been disabled. These protocols are NOT used by Java Plugin applets and Java Web Start applications by default. In case of any issues there is an option to re-enable the protocols via Java Control Panel.
JDK-8255892 (not public)

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u291) be used after the next critical patch update scheduled for July 20, 2021.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

Bug Fixes

» 8u291 Release notes

Java 8 Update 281 (8u281)

Release Highlights

IANA Data 2020d
JDK 8u281 contains IANA time zone data version 2020d. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: groupname Option Added to keytool Key Pair Generation
A new -groupname option has been added to keytool -genkeypair so that a user can specify a named group when generating a key pair. For example, keytool -genkeypair -keyalg EC -groupname secp384r1 will generate an EC key pair by using the secp384r1 curve. Because there might be multiple curves with the same size, using the -groupname option is preferred over the -keysize option.
See JDK-8213400
New Feature: Apache Santuario Library Updated to Version 2.1.4
The Apache Santuario library has been upgraded to version 2.1.4. As a result, a new system property com.sun.org.apache.xml.internal.security.parser.pool-size has been introduced.
This new system property sets the pool size of the internal DocumentBuilder cache used when processing XML Signatures. The function is equivalent to the org.apache.xml.security.parser.pool-size system property used in Apache Santuario and has the same default value of 20.
See JDK-8231507
New Feature: Support for certificate_authorities Extension
The "certificate_authorities" extension is an optional extension introduced in TLS 1.3. It is used to indicate the certificate authorities (CAs) that an endpoint supports and should be used by the receiving endpoint to guide certificate selection.
See JDK-8206925
Other notes: Changed Properties.loadFromXML to Comply with Specification
The implementation of the java.util.Properties loadFromXML method has been changed to comply with its specification. Specifically, the underlying XML parser implementation now rejects non-compliant XML documents by throwing an InvalidPropertiesFormatException as specified by the loadFromXML method.
See JDK-8213325
Other notes: US/Pacific-New Zone Name Removed as Part of tzdata2020b
Following the JDK's update to tzdata2020b, the long-obsolete files named pacificnew and systemv have been removed. As a result, the "US/Pacific-New" Zone name declared in the pacificnew data file is no longer available for use.
See JDK-8254177

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u281) be used after the next critical patch update scheduled for April 20, 2021.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u281) on May 15, 2021. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u281 Release notes

Java 8 Update 271 (8u271)

Release Highlights

IANA Data 2020a
JDK 8u271 contains IANA time zone data version 2020a. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default
Weak named curves are disabled by default by adding them to the following disabledAlgorithms security properties: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms, and jdk.jar.disabledAlgorithms. With 47 weak named curves to be disabled, adding individual named curves to each disabledAlgorithms property would be overwhelming. To relieve this, a new security property, jdk.disabled.namedCurves, is implemented that can list the named curves common to all of the disabledAlgorithms properties. To use the new property in the disabledAlgorithms properties, precede the full property name with the keyword include. Users can still add individual named curves to disabledAlgorithms properties separate from this new property. No other properties can be included in the disabledAlgorithms properties.
See JDK-8233228
New Feature: Support for Kerberos Cross-Realm Referrals (RFC 6806)
The Kerberos client has been enhanced with the support of principal name canonicalization and cross-realm referrals, as defined by the RFC 6806 protocol extension.
As a result of this new feature, the Kerberos client can take advantage of more dynamic environment configurations and does not necessarily need to know (in advance) how to reach the realm of a target principal (user or service).
See JDK-8223172
Removed Feature: Java Plugin is Removed from JDK 8u for Linux, Solaris, and MacOS Platforms
NPAPI is considered to be a vulnerable plugin and has been disabled in many browsers. No browsers currently support Java Plugin, which is NPAPI-based, on Linux, Solaris, and MacOS platforms.
Starting from 8u271, the part of Java Plugin responsible for integration and interaction with a browser (in particular libnpjp2 library) and an associated artifact will not be built and is not part of the JRE distribution on Linux, Solaris, and MacOS platforms.
JDK-8240210 (not public)
Other notes: Added Property to Control LDAP Authentication Mechanisms Allowed to Authenticate Over Clear Connections
A new environment property, jdk.jndi.ldap.mechsAllowedToSendCredentials, has been added to control which LDAP authentication mechanisms are allowed to send credentials over clear LDAP connections - a connection not secured with TLS. An encrypted LDAP connection is a connection opened by using ldaps scheme, or a connection opened by using ldap scheme and then upgraded to TLS with a STARTTLS extended operation.
JDK-8237990 (not public)

Keeping the JDK up to Date

Oracle recommends that the JDK is updated with each Critical Patch Update (CPU). In order to determine if a release is the latest, the following Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u271) be used after the next critical patch update scheduled for January 19, 2021.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u271) on February 20, 2021. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u271 Release notes

Java 8 Update 261 (8u261)

Release Highlights

IANA Data 2020a
JDK 8u261 contains IANA time zone data version 2020a. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: JDK/JRE Runtime Windows Visual Studio Library (DLL) Dependency Changes
As part of ongoing maintenance, the Microsoft Visual Studio 2017 tool chain will be used to build JDK 7 and JDK 8 for Windows. JDK 8u261, in the July 2020 CPU, was built with Visual Studio 2017. With the release of the October 2020 CPU, JDK 7u281 will move to Visual Studio 2017.
JDK-8246783 (not public)
New Feature: JEP 332 Transport Layer Security (TLS) 1.3
JDK 8u261 includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the Java Secure Socket Extension (JSSE) Reference Guide documentation and JEP 332.
See JDK-814252
New Feature: New System Properties to Configure the TLS Signature Schemes
Two new System Properties are added to customize the TLS signature schemes in JDK.
jdk.tls.client.SignatureSchemes is added for TLS client side, and jdk.tls.server.SignatureSchemes is added for server side.
See JDK-8242141
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.enableFFDHE to false.
See JDK-8140436

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u261) be used after the next critical patch update scheduled for October 13, 2020.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u261) on November 13, 2020. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u261 Release notes

Java 8 Update 251 (8u251)

Release Highlights

IANA Data 2019c
JDK 8u251 contains IANA time zone data version 2019c. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature
The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the java.security.spec and javax.crypto.spec packages for supporting additional RSASSA-PSS parameters.
See JDK-8146293
Other notes: WebEngine Limits JavaScript Method Calls for Certain Classes
JavaScript programs that are run in the context of a web page loaded by WebEngine can communicate with Java objects passed from the application to the JavaScript program. JavaScript programs that reference java.lang.Class objects are now limited to the following methods:
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

No methods can be called on the following classes:
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (not public)
Other notes: New Oracle Specific JDK 8 Updates System Property to Fallback to Legacy Base64 Encoding Format
Oracle JDK 8u231 upgraded the Apache Santuario libraries to v2.1.3. This upgrade introduced an issue where XML signature using Base64 encoding resulted in appending &#xd or &#13 to the encoded output. This behavioral change was made in the Apache Santuario codebase to comply with RFC 2045. The Santuario team has adopted a position of keeping their libraries compliant with RFC 2045.
See JDK-8236645

Keeping the JDK up to Date

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u251) be used after the next critical patch update scheduled for July 14, 2020.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u251) on August 14, 2020. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Bug Fixes

» 8u251 Release notes

Java 8 Update 241 (8u241)

Release Highlights

IANA Data 2019c
JDK 8u241 contains IANA time zone data version 2019c. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Allow SASL Mechanisms to Be Restricted
A security property named jdk.sasl.disabledMechanisms has been added that can be used to disable SASL mechanisms. Any disabled mechanism will be ignored if it is specified in the mechanisms argument of Sasl.createSaslClient or the mechanism argument of Sasl.createSaslServer. The default value for this security property is empty, which means that no mechanisms are disabled out-of-the-box.
See JDK-8200400
New Feature: SunPKCS11 Provider Upgraded with Support for PKCS#11 v2.40
The SunPKCS11 provider has been updated with support for PKCS#11 v2.40. This version adds support for more algorithms such as the AES/GCM/NoPadding cipher, DSA signatures using SHA-2 family of message digests, and RSASSA-PSS signatures when the corresponding PKCS11 mechanisms are supported by the underlying PKCS11 library.
See JDK-8080462
Other notes: New Checks on Trust Anchor Certificates
New checks have been added to ensure that trust anchors are CA certificates and contain proper extensions. Trust anchors are used to validate certificate chains used in TLS and signed code. Trust anchor certificates must include a Basic Constraints extension with the cA field set to true. Also, if they include a Key Usage extension, the keyCertSign bit must be set.
JDK-8230318 (not public)
Other notes: Exact Match Required for Trusted TLS Server Certificate
A TLS server certificate must be an exact match of a trusted certificate on the client in order for it to be trusted when establishing a TLS connection.
JDK-8227758 (not public)
Other notes: Added LuxTrust Global Root 2 Certificate
LuxTrust root certificate has been added to the cacerts truststore
See JDK-8232019
Other notes: Added 4 Amazon Root CA Certificates
Amazon root certificate has been added to the cacerts truststore
See JDK-8233223
Bug Fixes: Support for OpenType CFF Fonts
Previously, Oracle JDK 8 did not include OpenType CFF fonts (.otf fonts) into the standard logical fonts (such as "Dialog" and "SansSerif"). This resulted in missing glyphs when rendering text. In the most extreme cases where only CFF fonts were installed on the system, a Java exception could be thrown.
Several Linux distributions were affected by this issue because they rely on CFF fonts to support some languages, which is common for CJK (Chinese, Japanese, and Korean) languages.
Oracle JDK 8 now uses these CFF fonts, and this issue has been resolved.
See JDK-8209672
Bug Fixes: Better Serial Filter Handling
The jdk.serialFilter system property can only be set on the command line. If the filter has not been set on the command line, it can be set can be set with java.io.ObjectInputFilter.Config.setSerialFilter. Setting the jdk.serialFilter with java.lang.System.setProperty has no effect.
JDK-8231422 (not public)

Java Expiration Date

The expiration date for 8u241 is April 14, 2020. 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 8u241) on May 14, 2020. 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

» 8u241 Release notes

Java 8 Update 231 (8u231)

Release Highlights

IANA Data 2019b
JDK 8u231 contains IANA time zone data version 2019b. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: New jdk.jceks.iterationCount System Property
A new system property has been introduced to control the iteration count value used for the jceks keystore. The default value remains at 200000 but values between 10000 and 5000000 may be specified. The new system property name is jdk.jceks.iterationCount and the value supplied should be an integer in the accepted range. The default value will be used if a parsing error is encountered.
JDK-8223269 (not public)
New Feature: New Java Flight Recorder (JFR) Security Events
Four new JFR events have been added to the security library area. These events are disabled by default and can be enabled via the JFR configuration files or via standard JFR options.
See JDK-8148188
Removed Features and Options: Removal of T2K Rasterizer and ICU Layout Engine From JavaFX
The T2K rasterizer and ICU layout engine have been removed from JavaFX.
See JDK-8187147
Other notes: [client-libs and javaFX] GTK3 Is Now the Default on Linux/Unix
Newer versions of Linux, Solaris, and other Unix flavor desktop environments use GTK3, while still supporting GTK2.
Previously, the JDK would default to loading the older GTK2 libraries. However, in this release, it defaults to loading GTK3 libraries. Loading is typically triggered by using the Swing GTK Look And Feel.
The old behavior can be restored by using the system property: -Djdk.gtk.version=2.2
See JDK-8222496
Other notes: Remove Obsolete NIST EC Curves from the Default TLS Algorithms
This change removes obsolete NIST EC curves from the default Named Groups used during TLS negotiation. The curves removed are sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, and secp256k1.
To re-enable these curves, use the jdk.tls.namedGroups system property. The property contains a comma-separated list within quotation marks of enabled named groups in preference order. For example:
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (not public)

Java Expiration Date

The expiration date for 8u231 is January 14, 2020. 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 8u231) on February 14, 2020. 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

» 8u231 Release notes

Java 8 Update 221 (8u221)

Release Highlights

IANA Data 2018i
JDK 8u221 contains IANA time zone data version 2018i. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: HotSpot Windows OS Detection Correctly Identifies Windows Server 2019
Prior to this fix, Windows Server 2019 was recognized as "Windows Server 2016", which produced incorrect values in the os.name system property and the hs_err_pid file.
See JDK-8211106
Removed Features and Options: Removal of Two DocuSign Root CA Certificates
Two DocuSign root CA certificates are expired and have been removed from the cacerts keystore:
- alias name "certplusclass2primaryca [jdk]"
  Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
- alias name "certplusclass3pprimaryca [jdk]"
  Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR
See JDK-8223499
Removed Features and Options: Removal of Two Comodo Root CA Certificates
Two Comodo root CA certificates are expired and have been removed from the cacerts keystore:
- alias name "utnuserfirstclientauthemailca [jdk]"
  Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
- alias name "utnuserfirsthardwareca [jdk]"
  Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
See JDK-8222136
Removed Features and Options: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate
The T-Systems Deutsche Telekom Root CA 2 certificate is expired and has been removed from the cacerts keystore:
- alias name "deutschetelekomrootca2 [jdk]"
  Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
See JDK-8222137
Other notes: Java Access Bridge Installation Workaround
There is a risk of breaking Java Access Bridge functionality when installing Java on a Windows system that has both a previously installed version of Java and an instance of JAWS running. After rebooting, the system can be left without the WindowsAccessBridge-64.dll in either the system directory (C:\Windows\System32) for 64bit Java products or the system directory used by WOW64 (C:\Windows\SysWoW64) for 32bit Java products.
To prevent breaking Java Access Bridge functionality, use one of the following workarounds:
- Stop JAWS before running the Java installer.
- Uninstall the existing JRE(s) before installing the new version of Java.
- Uninstall the existing JRE(s) after the new version of Java is installed and the machine is rebooted.
The goal of the workarounds is to avoid the scenario of uninstalling existing JRE(s) from Java installer when JAWS is running.
JDK-8223293 (not public)

Java Expiration Date

The expiration date for 8u221 is October 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 8u221) on November 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

» 8u221 Release notes

Java 8 Update 211 (8u211)

Release Highlights

IANA Data 2018g
JDK 8u211 contains IANA time zone data version 2018g. For more information, refer to Timezone Data Versions in the JRE Software.
New Feature: Square Character Support for Japanese New Era
The code point, U+32FF, is reserved by the Unicode Consortium to represent the Japanese square character for the new era that begins from May, 2019. Relevant methods in the Character class return the same properties as the existing Japanese era characters (e.g., U+337E for "Meizi"). For details about the code point, see http://blog.unicode.org/2018/09/new-japanese-era.html.
See JDK-8211398
Change: Added GlobalSign R6 Root Certificate
The following root certificate has been added to the OpenJDK cacerts truststore:
- GlobalSign
  - globalsignrootcar6
    DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6
JDK-8216577 (not public)
Change: Distrust TLS Server Certificates Anchored by Symantec Root
The JDK will stop trusting TLS Server certificates issued by Symantec, in line with similar plans recently announced by Google, Mozilla, Apple, and Microsoft. The list of affected certificates includes certificates branded as GeoTrust, Thawte, and VeriSign, which were managed by Symantec.
TLS Server certificates issued on or before April 16, 2019 will continue to be trusted until they expire. Certificates issued after that date will be rejected. See the DigiCert support page for information on how to replace your Symantec certificates with a DigiCert certificate (DigiCert took over validation and issuance for all Symantec Website Security SSL/TLS certificates on December 1, 2017).
An exception to this policy is that TLS Server certificates issued through two subordinate Certificate Authorities managed by Apple, and identified below, will continue to be trusted as long as they are issued on or before December 31, 2019.
See JDK-8207258
Change: New Japanese Era Name
The placeholder name, "NewEra", for the Japanese era that started from May 1st, 2019 has been replaced with the Japanese Government declared name "Reiwa". Applications that rely on the placeholder name to obtain the new era singleton (JapaneseEra.valueOf("NewEra")) will no longer work.
See JDK-8205432
Change: Support New Japanese Era in java.time.chrono.JapaneseEra
The JapaneseEra class and its of(int) valueOf(String) and values() methods are clarified to accommodate future Japanese era additions, such as how the singleton instances are defined, what the associated integer era values are, etc.
See JDK-8212941

Java Expiration Date

The expiration date for 8u211 is July 16, 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 8u211) on August 16, 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 8u211 Bug Fixes page.

» 8u211 Release notes

Java 8 Update 201 (8u201)

Release Highlights

IANA Data 2018e
JDK 8u201 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.
Change: TLS anon and NULL Cipher Suites are Disabled
The TLS anon (anonymous) and NULL cipher suites have been added to the jdk.tls.disabledAlgorithms security property and are now disabled by default.
See JDK-8211883
Change: jarsigner Prints When a timestamp Will Expire
The jarsigner tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year.
See JDK-8191438

Java Expiration Date

The expiration date for 8u201 is April 16, 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 8u201) on May 16, 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

» 8u201 Release notes

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

» 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=ch
JDK-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:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- Attach DumpJFR to a core file:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
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:
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

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