Consolidated Release Notes for JDK 8 and JDK 8 Update Releases

BPR builds are available only as commercial offerings to Oracle customers. They include fixes critical to customers that could not wait until the next scheduled release. Fixes introduced on BPRs are added to later GA releases.

Java SE 8u291 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u291 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in the previous BPR are also included in the current BPR.

Changes in Java SE 8u291 b33

Bug Fixes

Java™ SE Development Kit 8, Update 291 (JDK 8u291)

April 20, 2021

The full version string for this update release is 1.8.0_291-b10 (where "b" means "build"). The version number is 8u291.

IANA TZ Data 2020e, 2020f, 2021a

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u291 are specified in the following table:

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.

Other Notes

+ HARICA
  + haricarootca2015
    DN: CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR

  + haricaeccrootca2015
    DN: CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR

Java SE 8u281 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u281 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in the previous BPR are also included in the current BPR.

Changes in Java SE 8u281 b35

Bug Fixes

Java™ SE Development Kit 8, Update 281 (JDK 8u281)

January 19, 2021

The full version string for this update release is 1.8.0_281-b09 (where "b" means "build"). The version number is 8u281.

IANA Data 2020d

JDK 8u281 contains IANA time zone data version 2020d. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u281 are specified in the following table:

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

New Features

Other Notes

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 the JDK 8u281 Bug Fixes page.

Java SE 8u271 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u271 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in the previous BPR are also included in the current BPR.

Changes in Java SE 8u271 b37

Bug Fixes

Java™ SE Development Kit 8, Update 271 (JDK 8u271)

October 20, 2020

The full version string for this update release is 1.8.0_271-b09 (where "b" means "build"). The version number is 8u271.

IANA Data 2020a

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u271 are specified in the following table:

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

New Features

Removed Features and Options

Other notes

+ SSL Corporation
  + sslrootrsaca
    DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US

  + sslrootevrsaca
    DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US

  + sslrooteccca
    DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US

+ Entrust
  + entrustrootcag4
    DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", 
        OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

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 the JDK 8u271 Bug Fixes page.

Java SE 8u261 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u261 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 8u261 b36

Bug Fixes

Changes in Java SE 8u261 b34

Bug Fixes

Changes in Java SE 8u261 b33

Bug Fixes

Java™ SE Development Kit 8, Update 261 (JDK 8u261)

July 14, 2020

The full version string for this update release is 1.8.0_261-b12 (where "b" means "build"). The version number is 8u261.

IANA Data 2020a

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u261 are specified in the following table:

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 8u261) be used after the next critical patch update scheduled for October 20, 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 17, 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.

New Features

Other Notes

javax.net.ssl|SEVERE|C8|....|TransportContext.java:319|Fatal (HANDSHAKE_FAILURE): Received fatal
alert: handshake_failure (
"throwable" : {
  javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
        at sun.security.ssl.Alert.createSSLException(Alert.java:131)
        at sun.security.ssl.Alert.createSSLException(Alert.java:117)
        at sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
        at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
        at sun.security.ssl.TransportContext.dispatch(TransportContext.java:187)
        at sun.security.ssl.SSLTransport.decode(SSLTransport.java:154)
        at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1198)
        at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1107)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:400)
       at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:372)

javax.net.ssl.SSLProtocolException: Received close_notify during handshake

       at sun.security.ssl.Alert.createSSLException(Unknown Source)
        at sun.security.ssl.Alert.createSSLException(Unknown Source)
        at sun.security.ssl.TransportContext.fatal(Unknown Source)
        at sun.security.ssl.TransportContext.fatal(Unknown Source)
        at sun.security.ssl.TransportContext.fatal(Unknown Source)
        at sun.security.ssl.Alert$AlertConsumer.consume(Unknown Source)
        at sun.security.ssl.TransportContext.dispatch(Unknown Source)
        at sun.security.ssl.SSLTransport.decode(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.decode(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown

   HashMap$Node[] java.util.HashMap.resize()
   void sun.security.ssl.SSLSessionContextImpl.put(SSLSessionImpl)
   void sun.security.util.MemoryCache.put(Object, Object)
   Object java.util.HashMap.put(Object, Object)
   Object java.util.HashMap.putVal(int, Object, Object, boolean, boolean)
   HashMap$Node[] java.util.HashMap.resize()

javax.net.ssl|WARNING|03|Finalizer|2020-08-31 09:42:20.203 EDT|null:-1|SSLSocket duplex close failed (
"throwable" : {
java.net.SocketException: Socket is not connected
at java.net.Socket.shutdownOutput(Unknown Source)
at sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(Unknown Source)
at sun.security.ssl.SSLSocketImpl.duplexCloseOutput(Unknown Source)
at sun.security.ssl.SSLSocketImpl.close(Unknown Source)
at sun.security.ssl.BaseSSLSocketImpl.finalize(Unknown Source)
at java.lang.System$2.invokeFinalize(Unknown Source)
at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
at java.lang.ref.Finalizer.access$100(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)}

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

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 the JDK 8u261 Bug Fixes page.

Java SE 8u251 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u251 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 8u251 b36

Bug Fixes

Java™ SE Development Kit 8, Update 251 (JDK 8u251)

April 14, 2020

The full version string for this update release is 1.8.0_251-b08 (where "b" means "build"). The version number is 8u251. This JDK 8 Update release implements JSR 337 Maintenance Release 3 (approved Feb 2020).

IANA Data 2019c

JDK 8u251 contains IANA time zone data version 2019c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u251 are specified in the following table:

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 8u251) be used after the next critical patch update scheduled for July 14, 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 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.

New Features

security-libs/javax.net.ssl
➜ TLS Application-Layer Protocol Negotiation Extension

JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the javax.net.ssl classes SSLEngine, SSLSocket, and SSLParameters to allow clients and servers to negotiate an application layer value as part of the TLS handshake.

This API change was required by JSR 337 MR 3.

security-libs/javax.crypto
➜ RSASSA-PSS Signature Support Added to SunMSCAPI

The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider.

security-libs/java.security
➜ 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.

This API change was required by JSR 337 MR 3.

Other notes

javafx/web
➜ 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.*

security-libs/javax.xml.crypto
➜ 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.

Oracle JDK 8u221 using the legacy encoder returns encoded data in a format without &#xd or &#13.

Therefore, a new Oracle JDK 8 Updates only system property, - com.sun.org.apache.xml.internal.security.lineFeedOnly, is made available to fall back to legacy Base64 encoded format.

Users can set this flag in one of two ways:

1. -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=true
2. System.setProperty("com.sun.org.apache.xml.internal.security.lineFeedOnly", "true")

This new system property is disabled by default. It has no effect on default behavior nor when com.sun.org.apache.xml.internal.security.ignoreLineBreaks property is set.

Later JDK family versions might only support the recommended property: com.sun.org.apache.xml.internal.security.ignoreLineBreaks

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 the JDK 8u251 Bug Fixes page.

Java SE 8u241 BPRs, are based on the current Java SE 8u241 release and are available for Java SE Subscription customers. This release is also available for legacy Java SE Suite, Java SE Advanced, and Java SE Support and when directed by support to be used as part of another Oracle product.

For more information on installation and licensing of Java SE Products, visit Java SE Products Overview.

Find information about Java SE Subscriptions at Oracle Java SE Subscriptions.

Java SE 8u241 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u241 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 8u241 b33

Bug Fixes

Changes in Java SE 8u241 b32

Bug Fixes

Changes in Java SE 8u241 b31

Bug Fixes

Java™ SE Development Kit 8, Update 241 (JDK 8u241)

January 14, 2020

The full version string for this update release is 1.8.0_241-b07 (where "b" means "build"). The version number is 8u241.

IANA Data 2019c

JDK 8u241 contains IANA time zone data version 2019c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u241 are specified in the following table:

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 8u241) be used after the next critical patch update scheduled for April 14, 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 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. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

New Features 

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

security-libs/javax.crypto:pkcs11
➜ 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.

Other notes

security-libs/java.security
➜ 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.

A new system property named jdk.security.allowNonCaAnchor has been introduced to restore the previous behavior, if necessary. If the property is set to the empty String or "true" (case-insensitive), trust anchor certificates can be used if they do not have proper CA extensions.

The default value of this property, if not set, is "false".

Note that the property does not apply to X.509 v1 certificates (since they don't support extensions).

This property is currently used by the JDK implementation. It is not guaranteed to be supported by other Java SE implementations.

security-libs/java.security
➜ 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.

security-libs/java.security
➜  Added LuxTrust Global Root 2 Certificate 

The following root certificate has been added to the cacerts truststore:

+ LuxTrust
     + luxtrustglobalroot2ca
 
         DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU

security-libs/java.security
➜ Added 4 Amazon Root CA Certificates

The following root certificates have been added to the cacerts truststore:

+ Amazon
     + amazonrootca1
         DN: CN=Amazon Root CA 1, O=Amazon, C=US
 
     + amazonrootca2
         DN: CN=Amazon Root CA 2, O=Amazon, C=US
 
     + amazonrootca3
         DN: CN=Amazon Root CA 3, O=Amazon, C=US
 
     + amazonrootca4
         DN: CN=Amazon Root CA 4, O=Amazon, C=US

core-libs/java.rmi
➜ Improve Registry Support

The java.rmi.Remote marker interface identifies interfaces containing methods that can be invoked remotely by using the following specification:

• Methods declared in interfaces that directly or indirectly extend java.rmi.Remote can be invoked remotely
• Methods declared in interfaces that do not extend Remote directly or indirectly cannot be invoked remotely

This affects remote objects in the java.rmi.registry.Registry and any other remote object.

Bug Fixes

The following are some of the notable bug fixes included in this release:

client-libs/2d
➜ 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.

core-libs/java.io:serialization
➜  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.

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 the JDK 8u241 Bug Fixes page.

Java SE 8u231 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u231 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 8u231 b34

Bug Fixes

Changes in Java SE 8u231 b33

Bug Fixes

Changes in Java SE 8u231 b32

Bug Fixes

Java™ SE Development Kit 8, Update 231 (JDK 8u231)

October 15, 2019

The full version string for this update release is 1.8.0_231-b11 (where "b" means "build"). The version number is 8u231.

IANA Data 2019b

JDK 8u231 contains IANA time zone data version 2019b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u231 are specified in the following table:

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 8u231) be used after the next critical patch update scheduled for January 14, 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 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. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

New Features

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

security-libs/java.security
➜ 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.

• java/security_property

  • Records Security.setProperty(String key, String value) method calls

• java/tls_handshake

  • Records TLS handshake activity. The event fields include:
    • Peer hostname
    • Peer port
    • TLS protocol version negotiated
    • TLS cipher suite negotiated
    • Certificate id of peer client

• java/x509_validation

  • Records details of X.509 certificates negotiated in successful X.509 validation (chain of trust)

• java/x509_certificate

  • Records details of X.509 Certificates. The event fields include:
    • Certificate algorithm
    • Certificate serial number
    • Certificate subject
    • Certificate issuer
    • Key type
    • Key length
    • Certificate id
    • Validity of certificate

Removed Features and Options

javafx/graphics
➜ Removal of T2K Rasterizer and ICU Layout Engine From JavaFX 

The T2K rasterizer and ICU layout engine have been removed from JavaFX.

Other notes

client-libs
➜ [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

docs
➜ Using the JDK or JRE on macOS Catalina (10.15)

Changes introduced in macOS 10.15 (Catalina) have caused JCK test failures which will prevent Java from being supported on macOS 10.15. If you still want to install and test then please see http:/java/technologies/javase/jdk-jre-macos-catalina.html.

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

security-libs/javax.xml.crypto
➜ Updated xmldsig Implementation to Apache Santuario 2.1.3 

The XML Signature implementation in this release has been updated to version 2.1.3 of Apache Santuario. New features include:

• Added support for embedding elliptic curve public keys in the KeyValue element

Earlier features from version 2.1.1 include: 

• Support for the SHA-224 and SHA-3 DigestMethod algorithms specified in RFC 6931.
• Support for the HMAC-SHA224, RSA-SHA224, ECDSA-SHA224, and RSASSA-PSS family of SignatureMethod algorithms specified in RFC 6931.

security-libs/javax.xml.crypto
➜ Updated xmldsig Implementation to Apache Santuario 2.1.1

The XMLDSig provider implementation in the java.xml.crypto module has been updated to version 2.1.1 of Apache Santuario. New features include:

• Support for the SHA-224 and SHA-3 DigestMethod algorithms specified in RFC 6931.
• Support for the HMAC-SHA224, RSA-SHA224, ECDSA-SHA224, and RSASSA-PSS family of SignatureMethod algorithms specified in RFC 6931.

security-libs/javax.crypto
➜ System Property jdk.security.useLegacyECC is Turned Off by Default

The system property jdk.security.useLegacyECC, which was introduced in the update releases 7u231 and 8u221, is turned off by default.

This option allows control of which implementation of ECC is in use.

When the system property, jdk.security.useLegacyECC, is explicitly set to "true" (the value is case-insensitive) the JDK uses the old, native implementation of ECC. If the option is set to an empty string, it is treated as if it were set to "true". This makes it possible to specify -Djdk.security.useLegacyECC in the command line. Setting the option to true or the empty string is not recommended.

If the option is set to "false", or if it is not specified at all, the provider decides which implementation of ECC is used. This is the recommended setting, as the JDK will use modern and timing resistant implementations of the NIST secp256r1, secp384r1, and secp521r1 curves. For more information on which curves are recommended and which are legacy, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunEC.

Java SE 8u221 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u221 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 8u221 b36

Bug Fixes

Changes in Java SE 8u221 b35

Bug Fixes

Changes in Java SE 8u221 b34

Bug Fixes

Changes in Java SE 8u221 b33

Bug Fixes

Changes in Java SE 8u221 b32

Please note that fixes from prior BPR are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 221 (JDK 8u221)

July 16, 2019

The full version string for this update release is 1.8.0_221-b11 (where "b" means "build"). The version number is 8u221.

IANA Data 2018i

JDK 8u221 contains IANA time zone data version 2018i. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u221 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. This JRE (version 8u221) will expire with the release of the next critical patch update scheduled for October 15, 2019.

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. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

New Features

hotspot/runtime

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

security-libs/java.security

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

security-libs/java.security

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

security-libs/java.security

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

install

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)

security-libs/javax.crypto

System Property to Switch Between Implementations of ECC

A new boolean system property, jdk.security.useLegacyECC, has been introduced that enables switching between implementations of ECC.

When the system property, jdk.security.useLegacyECC, is set to "true" (the value is case-insensitive) the JDK uses the old, native implementation of ECC. If the option is set to an empty string, it is treated as if it were set to "true". This makes it possible to specify -Djdk.security.useLegacyECC in the command line.

If the option is explicitly set to "false", the provider decides which implementation of ECC is used.

The default value of the option is "true". Note that the default value might change in a future update release of the JDK.

JDK-8217763 (not public)

client-libs/2d

Missing Glyphs in AWT/Swing Components Due to Lack of CJK TrueType Fonts in RHEL 8

Red Hat Enterprise Linux 8 no longer includes packages which provided TrueType fonts used by JDK for CJK (Chinese, Japanese, and Korean) languages.

Text display for those languages will therefore result in missing glyphs.

See JDK-8209672 for a resolution to this issue.

See JDK-8230150

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 the JDK 8u221 Bug Fixes page.

Java SE 8u212 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u212 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u212 b34

Please note that fixes in 8u212 b34 are included in 8u221-b32.

Bug Fixes

Changes in Java SE 8u212 b33

Bug Fixes

Changes in Java SE 8u212 b32

Bug Fixes

Changes in Java SE 8u212 b31

Please note that fixes from prior BPR (8u202 b34) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 212 (JDK 8u212)

April 16, 2019

The full version string for this update release is 1.8.0_212-b10 (where "b" means "build"). The version number is 8u212.

IANA Data 2018g

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u212 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u212) will expire with the release of the next critical patch update scheduled for July 16, 2019.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u212) 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. 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 the JDK 8u212 Bug Fixes page.

Java™ SE Development Kit 8, Update 211 (JDK 8u211)

April 16, 2019

The full version string for this update release is 1.8.0_211-b12 (where "b" means "build"). The version number is 8u211.

IANA Data 2018g

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u211 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. This JRE (version 8u211) will expire with the release of the next critical patch update scheduled for July 16, 2019.

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. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

New Features

core-libs/java.time

 New Japanese Era Name Reiwa

An instance representing the new Reiwa era has been added to this update. Unlike other eras, there is no public field for this era. It can be obtained by calling JapaneseEra.of(3) or JapaneseEra.valueOf("Reiwa"). JDK 13 and later will have a new public field to represent this era.

The placeholder name, "NewEra", for the Japanese era that started from May 1st, 2019 has been replaced with the new official name. Applications that relied on the placeholder name (see JDK-8202088) to obtain the new era singleton (JapaneseEra.valueOf("NewEra")) will no longer work.

See JDK-8205432

core-libs/java.util:i18n

 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

client-libs/2d

 High DPI Auto-Scaling on Windows

If the Windows desktop DPI of the default screen is configured via Display Settings to be 150% or greater (that is 144 dpi or greater), JDK will now ask Windows to auto-scale the entire UI of a Java application to be consistent with the rest of the Windows desktop UI.

Below that value Java applications will appear at the same size as they did in previous releases.

This threshold is chosen as a trade-off between compatibility and legibility of the UI. At higher DPI settings, without this auto-scaling, the Java UI may be just too small to be read comfortably.

There may be some negative consequences such as

• Some elements of the UI may appear somewhat blurry, particularly if the scaling factor is a non-integral value (that is 1.5 rather than 2.0).
• ClearType text is not effective when auto-scaling so grey scale anti-aliasing is used instead by the Swing toolkit.
• Window sizing and positioning calculations may be adversely affected.

In the event that the negative consequences outweigh the benefits, an application can request the old behaviour by specifying:

-Dsun.java2d.dpiaware=true

Conversely, if the application would prefer to be auto-scaled even at lower DPI settings, then specify:

-Dsun.java2d.dpiaware=false

In the absence of either explicit setting, the default behaviour described above will apply.

JDK-8204512 (not public)

core-libs/java.lang

 New Currency Code Points Added

The Java SE 8 Platform spec for java.lang.Character now supports Unicode 6.2 plus an extension to allow new currency code points from Unicode 10.0.

The following currency code points have been added:

    0BB NORDIC MARK SIGN
    20BC  MANAT  SIGN
    20BD RUBLE SIGN
    20BE LARI SIGN
    20BF BITCOIN SIGN

See JDK-8217710

Known Issues

install

 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)

hotspot/compiler

 Possible Performance Regression in JDK 8 Updates 202, 211, and 212

Due to a known issue with the fix for JDK-8155635, introduced in JDK 8 update 202, some applications may experience a performance regression (lower throughput and/or higher CPU consumption) when migrating from earlier releases. Examples of code that might trigger this regression include heavy use of sun.misc.Unsafe and the Reflection API. This performance regression is addressed in JDK-8221355.

See JDK-8221355

Changes

security-libs/java.security

 Added GlobalSign R6 Root Certificate 

The following root certificate has been added to the cacerts truststore:

• GlobalSign

  • globalsignrootcar6

    DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6

JDK-8216577 (not public)

security-libs/javax.net.ssl

 Distrust TLS Server Certificates Anchored by Symantec Root CAs 

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.

The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below.

An application will receive an Exception with a message indicating the trust anchor is not trusted, ex:

"TLS Server certificate issued after 2019-04-16 and anchored by a distrusted legacy Symantec root CA: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US"

If necessary, and at your own risk, you can work around the restrictions by removing "SYMANTEC_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Symantec Root certificates included in the JDK:

Root Certificates distrusted after 2019-04-16

Subordinate Certificates distrusted after 2019-12-31

If you have a TLS Server certificate issued by one of the CAs above, you should have received a message from DigiCert with information about replacing that certificate, free of charge.

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server if not yours.

See JDK-8207258

core-libs/java.time

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

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 the JDK 8u211 Bug Fixes page.

Java SE 8u202 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u202 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u202 b34

Bug Fixes

Changes in Java SE 8u202 b32

Bug Fixes

Changes in Java SE 8u202 b31

Please note that fixes from prior BPR (8u192 b35) are included in this version.

Java™ SE Development Kit 8, Update 202 (JDK 8u202)

January 15, 2019

The full version string for this update release is 1.8.0_202-b08 (where "b" means "build"). The version number is 8u202.

IANA Data 2018g

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u202 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u202) will expire with the release of the next critical patch update scheduled for April 16, 2019.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u202) 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. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Known Issues

client-libs

GTK+ 3.20 and Later Unsupported by Swing

Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore, Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release.

See JDK-8219072

Bug Fixes

The following are some of the notable bug fixes included in this release:

deploy/webstart

Changes in Update Process of Java Web Start Cached Objects

The update mechanism of cached Java Web Start objects has been slightly changed. Now Java Web Start issues HTTP HEAD request instead of GET to test whether the updates for cached object are available or not. The downloading of the updates did not change and keeps working in the same way as before.

JDK-8211746 (not public)

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 the JDK 8u202 Bug Fixes page.

Java™ SE Development Kit 8, Update 201 (JDK 8u201)

January 15, 2019

The full version string for this update release is 1.8.0_201-b09 (where "b" means "build"). The version number is 8u201.

IANA Data 2018g

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u201 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. This JRE (version 8u201) will expire with the release of the next critical patch update scheduled for April 16, 2019.

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. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Changes

security-libs/javax.net.ssl

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

security-libs/java.security

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

hotspot/runtime

Linux Native Code Checks 

Additional safeguards to protect against buffer overruns in native code have been enabled on Linux. If a buffer overrun is encountered the system will write the message “stack smashing detected” and the program will exit. Issues of this type should be reported to your vendor.

JDK-8196902 (not public)

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 the JDK 8u201 Bug Fixes page.

Java SE 8u192 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u192 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR. Note that bug fixes in previous BPR (8u181-b37) are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u192 b35

Bug Fixes

Changes in Java SE 8u192 b33

Bug Fixes

Changes in Java SE 8u192 b32

Bug Fixes

Changes in Java SE 8u192 b31

Please note that fixes from prior BPR (8u181 b37) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 192 (JDK 8u192)

October 16, 2018

The full version string for this update release is 1.8.0_192-b12 (where "b" means "build"). The version number is 8u192.

IANA Data 2018e

JDK 8u192 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u192 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u192) will expire with the release of the next critical patch update scheduled for January 15, 2019.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u192) 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. For more information, see JRE Expiration Date.

New Features

Support for Customization of Default Enabled Cipher Suites via System Properties 

The system property jdk.tls.client.cipherSuites can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property jdk.tls.server.cipherSuites can be used for customization on the server side.

The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicit setting of enabled cipher suites will override the system properties.

Please refer to the "Java Cryptography Architecture Standard Algorithm Name Documentation" for the standard JSSE cipher suite names, and the "Java Cryptography Architecture Oracle Providers Documentation" for the cipher suite names supported by the SunJSSE provider.

Note that the actual use of enabled cipher suites is restricted by algorithm constraints.

Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations.

Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk.

See JDK-8162362

Bug Fixes

This release 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 the JDK 8u192 Bug Fixes page.

Java™ SE Development Kit 8, Update 191 (JDK 8u191)

October 16, 2018

The full version string for this update release is 1.8.0_191-b12 (where "b" means "build"). The version number is 8u191.

IANA Data 2018e

JDK 8u191 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u191 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. This JRE (version 8u191) will expire with the release of the next critical patch update scheduled for January 15, 2019.

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. For more information, see JRE Expiration Date.

New Features

infrastructure/build

Build Environment Update Linux x86/x64 Moved to gcc 7.3

On x86/x64 Linux, the toolchain used to build the JDK has been upgraded from GCC 4.3 to GCC 7.3.

JDK-8206409 (not public)

Changes

core-svc

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)

security-libs/javax.net.ssl

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

security-libs/java.security

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

security-libs/java.security

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

security-libs/java.security

Removal of SECOM Root Certificate

The following SECOM root certificate is no longer in use and has been removed:

• secomevrootca1

  DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP

See JDK-8191844

hotspot/runtime

Java Improvements for Docker Containers

The following changes have been introduced in JDK 10 to improve the execution and configurability of Java running in Docker containers:

• JDK-8146115 Improve docker container detection and resource configuration usage

The JVM has been modified to be aware that it is running in a Docker container and will extract container specific configuration information instead of querying the operating system. The information being extracted is the number of CPUs and total memory that have been allocated to the container. The total number of CPUs available to the Java process is calculated from any specified cpu sets, cpu shares or cpu quotas. This support is only available on Linux based platforms. This new support is enabled by default and can be disabled in the command line with the JVM option:

-XX:-UseContainerSupport

In addition, this change adds a JVM option that provides the ability to specify the number of CPUs that the JVM will use:

-XX:ActiveProcessorCount=count

This count overrides any other automatic CPU detection logic in the JVM.

• JDK-8186248 Allow more flexibility in selecting Heap % of available RAM

Three new JVM options have been added to allow Docker container users to gain more fine grained control over the amount of system memory that will be used for the Java Heap:

• -XX:InitialRAMPercentage
• -XX:MaxRAMPercentage
• -XX:MinRAMPercentage

These options replace the deprecated Fraction forms (-XX:InitialRAMFraction, -XX:MaxRAMFraction, and -XX:MinRAMFraction).

• JDK-8179498 attach in linux should be relative to /proc/pid/root and namespace aware

This bug fix corrects the attach mechanism when trying to attach from a host process to a Java process that is running in a Docker container.

See JDK-8146115

security-libs/javax.crypto

Improved Cipher Inputs

The specification of javax.crypto.CipherInputStream has been clarified to indicate that this class may catch BadPaddingException and other exceptions thrown by failed integrity checks during decryption. These exceptions are not re-thrown, so the client may not be informed that integrity checks failed. Because of this behavior, this class may not be suitable for use with decryption in an authenticated mode of operation (e.g. GCM). Applications that require authenticated encryption can use the Cipher API directly as an alternative to using this class.

JDK-8201756 (not public)

Bug Fixes

The following are some of the notable bug fixes included in this release:

core-libs/javax.naming

LDAPS Communication Failure

Application code using LDAPS with a socket connect timeout that is <= 0 ( the default value ) 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: <server:port>; socket closed
at   com.sun.jndi.ldap.Connection.readReply(Unknown Source) 
at   com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source)
... 

See JDK-8211107

core-libs/java.net

Better HTTP Redirection Support

In this release, the behavior of methods which application code uses to set request properties in java.net.HttpURLConnection has changed. When a redirect occurs automatically from the original destination server to a resource on a different server, then all such properties are cleared for the redirect and any subsequent redirects. If these properties are required to be set on the redirected requests, then the redirect responses should be handled by the application by calling HttpURLConnection.setInstanceFollowRedirects(false) for the original request.

JDK-8196902 (not public)

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 the JDK 8u191 Bug Fixes page.

Java SE 8u181 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u181 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u181 b37

Bug Fixes

Changes in Java SE 8u181 b36

Bug Fixes

Changes in Java SE 8u181 b35

Bug Fixes

Changes in Java SE 8u181 b34

Bug Fixes

Changes in Java SE 8u181 b33

Bug Fixes

Changes in Java SE 8u181 b32

Please note that fixes from prior BPR (8u172 b37) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 181 (JDK 8u181)

July 17, 2018

The full version string for this update release is 1.8.0_181-b13 (where "b" means "build"). The version number is 8u181.

IANA Data 2018e

JDK 8u181 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u181 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. This JRE (version 8u181) will expire with the release of the next critical patch update scheduled for October 16, 2018.

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. For more information, see JRE Expiration Date.

Removed Features and Options

other-libs/javadb

 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)

Changes

core-libs/javax.naming

 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)

core-libs/java.io:serialization

 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 Fixes

The following are some of the notable bug fixes included in this release:

core-svc/debugger

 Unable to use the JDWP API in JDK 8 to debug JDK >=9

The implementation of VirtualMachineImpl.canGetInstanceInfo() has been corrected, so it is now able to see JDK JVMs >= JDK 9.

This correction allows certain debugger agents to operate correctly without any action required from a user (developer).

See JDK-8197943

hotspot/gc

 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.

In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded the classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash.

This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and it should not be unloaded.

See JDK-8187577

hotspot/gc

 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

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 the JDK 8u181 Bug Fixes page.

Java SE 8u172 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u172 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u172 b37

Bug Fixes

Changes in Java SE 8u172 b35

Bug Fixes

Changes in Java SE 8u172 b31

Please note that fixes from prior BPR (8u162 b37) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 172 (JDK 8u172)

April 17, 2018

The full version string for this update release is 1.8.0_172-b11 (where "b" means "build"). The version number is 8u172.

IANA Data 2018c

JDK 8u172 contains IANA time zone data version 2018c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u172 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u172) will expire with the release of the next critical patch update scheduled for July 17, 2018.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u172) 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. For more information, see JRE Expiration Date.

Known Issues

JDK-8154405

Changes

See JDK-8166772

Bug Fixes

This release 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 the JDK 8u172 Bug Fixes page.

Java™ SE Development Kit 8, Update 171 (JDK 8u171)

April 17, 2018

The full version string for this update release is 1.8.0_171-b11 (where "b" means "build"). The version number is 8u171.

IANA Data 2018c

JDK 8u171 contains IANA time zone data version 2018c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u171 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u171) will expire with the release of the next critical patch update scheduled for July 17, 2018.

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. For more information, see JRE Expiration Date.

Notes

security-libs/javax.crypto

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)

Known Issues

client-libs

Two files, jre/bin/javaw.exe and jre/bin/jabswitch.exe, were not included in 8u171. As a workaround, users who need those files can download the non-server JRE and copy those files from it into their server JRE image.

See JDK-8203544

New Features

security-libs/javax.crypto

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)

core-svc/java.lang.management

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)

Changes

security-libs/java.security

"TeliaSonera Root CA v1" has been added to the cacerts keystore.

JDK-8190851 (not public)

security-libs/javax.xml.crypto

XML Signatures Signed with EC Keys Less Than 224 Bits Disabled 

The secure validation mode of the XML Signature implementation has been enhanced to restrict EC keys less than 224 bits by default. The secure validation mode is enabled either by setting the property org.jcp.xml.dsig.secureValidation to true with the javax.xml.crypto.XMLCryptoContext.setProperty() method, or by running the code with a SecurityManager.

JDK-8186032 (not public)

security-libs/javax.net.ssl

3DES Cipher Suites 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)

core-libs/java.util.logging

System Property Controls java.util.logging.FileHandler's MAX_LOCKS Limit

A new JDK implementation specific system property jdk.internal.FileHandlerLogging.maxLocks has been introduced to control the java.util.logging.FileHandler MAX_LOCKS limit. The default value of the current MAX_LOCKS (100) is retained if this new system property is not set or an invalid value is provided to the property. Valid values for this property are integers ranging from 1 to Integer.MAX_VALUE-1.

See JDK-8153955

install

Change to Internal Java Package Names in RPM Installers 

On the Linux platform, the names of JRE and JDK packages provided by Java RPM installers have been changed. Names of JRE and JDK packages follow `jre ` and `jdk ` patterns respectively instead of the jre and jdk previously used. For example, the new names of JRE and JDK packages are jre1.8 and jdk1.8 respectively.

On Linux platform, the names of installation directories of Java products have also been changed. The installation directories of products from the 8u171 release are as follows:

• /usr/java/jre1.8.0_171-i586 for 32bit JRE
• /usr/java/jdk1.8.0_171-i586 for 32bit JDK
• /usr/java/jre1.8.0_171-amd64 for 64bit JRE
• /usr/java/jdk1.8.0_171-amd64 for 64bit JDK

See JDK-8191608

Bug Fixes

The following are some of the notable bug fixes included in this release:

core-libs/java.rmi

Server-side HTTP-tunneled RMI Connections Disabled

This release disables server side HTTP-tunneled RMI connections by default. The previous behavior can be re-enabled after due consideration of any impact by setting the runtime property sun.rmi.server.disableIncomingHttp to false. Note that 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)

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 the JDK 8u171 Bug Fixes page.

Java SE 8u162 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u162 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u162 b37

Bug Fixes

Changes in Java SE 8u162 b36

Bug Fixes

Changes in Java SE 8u162 b35

Bug Fixes

Changes in Java SE 8u162 b34

Bug Fixes

Changes in Java SE 8u162 b32

Bug Fixes

Changes in Java SE 8u162 b31

Bug Fixes

Java™ SE Development Kit 8, Update 162 (JDK 8u162)

January 16, 2018

The full version string for this update release is 1.8.0_162-b12 (where "b" means "build"). The version number is 8u162.

IANA Data 2017c

JDK 8u162 contains IANA time zone data version 2017c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u162 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u162) will expire with the release of the next critical patch update scheduled for April 17, 2018.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u162) 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. For more information, see JRE Expiration Date.

Changes

core-libs/java.rmi

 RMI Registry Filter Allows Binding Arrays of Any Type 

The RMI Registry built-in serial filter has been modified to check only the array size and not the component type. The maximum array size has been increased to 1,000,000. The override filter can be used to decrease the limit. Array sizes greater than the maxarray limit will be rejected. Sizes less than the maxarray limit will be allowed.

The java.security file contains more information about the sun.rmi.registry.registryFilter property and the conf/security/java.security configuration file has been updated to better describe the default behavior and how to override it.

See JDK-8185346

Bug Fixes

This release 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 the JDK 8u162 Bug Fixes page.

Java™ SE Development Kit 8, Update 161 (JDK 8u161)

January 16, 2018

The full version string for this update release is 1.8.0_161-b12 (where "b" means "build"). The version number is 8u161.

IANA Data 2017c

JDK 8u161 contains IANA time zone data version 2017c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u161 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u161) will expire with the release of the next critical patch update scheduled for April 17, 2018.

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. For more information, see JRE Expiration Date.

New Features

security-libs/javax.net.ssl

Added TLS session hash and extended master secret extension support

Support has been added for the TLS session hash and extended master secret extension (RFC 7627) in JDK JSSE provider. Note that in general, server certificate change is restricted if endpoint identification is not enabled and the previous handshake is a session-resumption abbreviated initial handshake, unless the identities represented by both certificates can be regarded as the same. However, if the extension is enabled or negotiated, the server certificate changing restriction is not necessary and will be discarded accordingly. In case of compatibility issues, an application may disable negotiation of this extension by setting the System Property jdk.tls.useExtendedMasterSecret to false in the JDK. By setting the System Property jdk.tls.allowLegacyResumption to false, an application can reject abbreviated handshaking when the session hash and extended master secret extension is not negotiated. By setting the System Property jdk.tls.allowLegacyMasterSecret to false, an application can reject connections that do not support the session hash and extended master secret extension.

See JDK-8148421

security-libs/javax.crypto

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

other-libs/corba

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)

Changes

security-libs/javax.crypto

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)

security-libs/javax.net.ssl

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)

security-libs/javax.crypto

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)

security-libs/javax.crypto

Stricter key generation

The generateSecret(String) method has been mostly disabled in the javax.crypto.KeyAgreement services of the SunJCE and SunPKCS11 providers. Invoking this method for these providers will result in a NoSuchAlgorithmException for most algorithm string arguments. The previous behavior of this method can be re-enabled by setting the value of the jdk.crypto.KeyAgreement.legacyKDF system property to true (case insensitive). Re-enabling this method by setting this system property is not recommended.

Prior to this change, the following code could be used to produce secret keys for AES using Diffie-Hellman:

KeyAgreement ka = KeyAgreement.getInstance("DiffieHellman");

ka.init(...);

ka.doPhase(...);

SecretKey sk = ka.generateSecret("AES");

The issue with this code is that it is unspecified how the provider should derive a secret key from the output of the Diffie-Hellman operation. There are several options for how this key derivation function can work, and each of these options has different security properties. For example, the key derivation function may bind the secret key to some information about the context or the parties involved in the key agreement. Without a clear specification of the behavior of this method, there is a risk that the key derivation function will not have some security property that is expected by the client.

To address this risk, the generateSecret(String) method of KeyAgreement was mostly disabled in the DiffieHellman services, and code like the example above will now result in a java.security.NoSuchAlgorithmException. Clients still may use the no-argument generateSecret method to obtain the raw Diffie-Hellman output, which can be used with an appropriate key derivation function to produce a secret key.

Existing applications that use the generateSecret(String) method of this service will need to be modified. Here are a few options:

A) Implement the key derivation function from an appropriate standard. For example, NIST SP 800-56Ar2[1] section 5.8 describes how to derive keys from Diffie-Hellman output.

B) Implement the following simple key derivation function:

1. Call KeyAgreement.generateSecret() to get the shared secret as a byte array
2. Hash the byte array produced in step 1 using SHA-256
3. Pass the byte array produced in step 2 into the constructor of SecretKeySpec. This constructor also

requires the standard name of the secret-key algorithm (e.g. "AES")

This is a simple key derivation function that may provide adequate security in a typical application. Developers should note that this method provides no protection against the reuse of key agreement output in different contexts, so it is not appropriate for all applications. Also, some additional effort may be required to enforce key size restrictions like the ones in Table 2 of NIST SP 800-57pt1r4[2].

C) Set the jdk.crypto.KeyAgreement.legacyKDF system property to "true". This will restore the previous behavior of this KeyAgreement service. This solution should only be used as a last resort if the application code cannot be modified, or if the application must interoperate with a system that cannot be modified. The "legacy" key derivation function and its security are unspecified.

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

JDK-8185292 (not public)

security-libs/javax.crypto

Unlimited cryptography enabled by default

The JDK uses the Java Cryptography Extension (JCE) Jurisdiction Policy files to configure cryptographic algorithm restrictions. Previously, the Policy files in the JDK placed limits on various algorithms. This release ships with both the limited and unlimited jurisdiction policy files, with unlimited being the default. The behavior can be controlled via the new 'crypto.policy' Security property found in the /lib/java.security file. Please refer to that file for more information on this property.

See JDK-8170157

core-libs/java.rmi

The RMI Registry filter is relaxed to allow binding arrays of any type

The RMI Registry built-in serial filter is modified to check only the array size and not the component type. The maximum array size is increased to 1,000,000. The override filter can be used to decrease the limit. Array sizes greater than the maxarray limit will be rejected and otherwise will be allowed. The java.security file contains more information about the sun.rmi.registry.registryFilter property and it will be updated in the conf/security/java.security configuration file to better describe the default behavior and how to override it.

See JDK-8185346

security-libs/javax.net.ssl

Disable exportable cipher suites

To improve the strength of SSL/TLS connections, exportable cipher suites have been disabled in SSL/TLS connections in the JDK by the jdk.tls.disabledAlgorithms Security Property.

See JDK-8163237

security-libs/java.security

Disable JARs signed with DSA keys less than 1024 bits

DSA keys less than 1024 bits have been added to the jdk.jar.disabledAlgorithms Security property in the java.security file. This property contains a list of disabled algorithms and key sizes for signed JAR files. If a 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 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 file.

Running jarsigner -verify -verbose 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 this command: jarsigner -verify -verbose test.jar

If the file in this example was signed with a weak key such as 512 bit DSA, this output would be seen:

- Signed by "CN=weak_signer"
Digest algorithm: SHA1 
Signature algorithm: SHA1withDSA, 512-bit key (weak)  

To address the issue, the JAR file will need to be re-signed with a stronger 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:

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-8185909 (not public)

core-svc/javax.management

JMX Connections need deserialization filters

New public attributes, RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and RMIConnectorServer.SERIAL_FILTER_PATTERN have been added to RMIConnectorServer.java. With these new attributes, users can specify the deserialization filter pattern strings to be used while making a RMIServer.newClient() remote call and while sending deserializing parameters over RMI to server respectively.

The user can also provide a filter pattern string to the default agent via management.properties. As a result, a new attribute is added to management.properties.

Existing attribute RMIConnectorServer.CREDENTIAL_TYPES is superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and has been removed.

JDK-8159377 (not public)

xml/jaxp

JDK Transform, Validation and XPath use the system-default parser

Java SE 9 changes the JDK's Transform, Validation and XPath implementations to use the JDK's system-default parser even when a third party parser is on the classpath. In order to override the JDK system-default parser, applications need to explicitly set the new System property jdk.xml.overrideDefaultParser.

1. Support through the API

   The overrideDefaultParser property is supported by the following APIs:

   1. TransformerFactory::setFeature
   2. SchemaFactory::setFeature
   3. Validator::setFeature
   4. XPathFactory::setFeature
2. Support as a System property

The overrideDefaultParser property can be set through the System.setProperty.

3. Support as a JAXP system property

The overrideDefaultParser property can be set in the JAXP configuration file jaxp.properties.

4. Scope and order

The overrideDefaultParser property follows the same rule as other JDK JAXP properties in that a setting of a narrower scope takes preference over that of a wider scope. A setting through the API overrides the System property which in turn overrides that in the jaxp.properties file.

JDK-8186080 (not public)

Bug Fixes

This release 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 the JDK 8u161 Bug Fixes page.

Java SE 8u152 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u152 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u152 b35

Bug Fixes

Changes in Java SE 8u152 b34

Bug Fixes

Changes in Java SE 8u152 b33

Bug Fixes

Changes in Java SE 8u152 b32

Bug Fixes

Changes in Java SE 8u152 b31

Please note that fixes from prior BPR (8u144 b34) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 152 (JDK 8u152)

October 17, 2017

The full version string for this update release is 1.8.0_152-b16 (where "b" means "build"). The version number is 8u152.

IANA Data 2017b

JDK 8u152 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

See JDK-8159684

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u152 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u152) will expire with the release of the next critical patch update scheduled for January 16, 2018.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u152) 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. For more information, see JRE Expiration Date.

Known Issues

core-libs/java.util.jar

 Decode error with Tomcat version 7.x

The zlib version shipped in the 8u151 and 7u161 JDK releases was updated to zlib v1.2.11. The deflate functionality in this version causes a compatibility issue with Tomcat v7.x. Server responses can appear as corrupt or can fail to be decoded. The issue is seen if Tomcat is using compression (e.g. compression="on" in server.xml). This issue is being fixed via JDK-8189789.

Users can disable the compression mode on their Tomcat servers as a workaround. Tomcat versions 8.x and later don't appear to be affected.

See JDK-8191040

New Features

security-libs/javax.crypto

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

hotspot/compiler

 BigInteger performance improvements turned on by default

The performance improvements described in JDK-8130150 and JDK-8081778 have now been turned on by default. They can be turned off by using the following command options:

-XX:-UseMontgomerySquareIntrinsic
-XX:-UseMontgomeryMultiplyIntrinsic
-XX:-UseSquareToLenIntrinsic 
-XX:-UseMultiplyToLenIntrinsic 

See JDK-8154945

Bug Fixes

The following are some of the notable bug fixes included in this release:

hotspot/compiler

 Compilers accept modification of final fields outside initializer methods

According to the Java VM Specification, final fields can be modified by the putfield byte code instruction only if the instruction appears in the instance initializer method <init> of the field's declaring class. Similar, static final fields can be modified by a putstatic instruction only if the instruction appears in the class initializer method <clinit> of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53 final fields can be modified in any method of the class declaring the field (not only class/instance initializers).

See JDK-8157181

This release 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 the JDK 8u152 Bug Fixes page.

Java™ SE Development Kit 8, Update 151 (JDK 8u151)

October 17, 2017

The full version string for this update release is 1.8.0_151-b12 (where "b" means "build"). The version number is 8u151.

IANA Data 2017b

JDK 8u151 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u151 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u151) will expire with the release of the next critical patch update scheduled for January 16, 2018.

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. For more information, see JRE Expiration Date.

Known Issues

core-libs/java.util.jar

Decode error with Tomcat version 7.x

The zlib version shipped in the 8u151 and 7u161 JDK releases was updated to zlib v1.2.11. The deflate functionality in this version causes a compatibility issue with Tomcat v7.x. Server responses can appear as corrupt or can fail to be decoded. The issue is seen if Tomcat is using compression (e.g. compression="on" in server.xml). This issue is being fixed via JDK-8189789.

Users can disable the compression mode on their Tomcat servers as a workaround. Tomcat versions 8.x and later don't appear to be affected.

See JDK-8191040

Notes

            /JDK8U141/bin/keytool -importkeystore \
-srckeystore /DIR/KEYSTORE \
-srcstoretype JCEKS \
-srcstorepass PASSWORD \
-destkeystore /DIR/KEYSTORE.NEW \
-deststoretype JCEKS \
-deststorepass PASSWORD 

        

        Swisscom Root EV CA 2
alias: "swisscomrootevca2 [jdk]"
DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
        

Java SE 8u144 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u144 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u144 b34

Bug Fixes

Changes in Java SE 8u144 b33

Bug Fixes

Changes in Java SE 8u144 b32

Bug Fixes

Changes in Java SE 8u144 b31

Please note that fixes from prior BPR (8u141 b32) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 144 (JDK 8u144)

July 26, 2017

The full version string for this update release is 1.8.0_144-b01 (where "b" means "build"). The version number is 8u144.

IANA Data 2017b

JDK 8u144 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u144 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u144) will expire with the release of the next critical patch update scheduled for October 17, 2017.

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. For more information, see JRE Expiration Date.

Changes

java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a / ended entry name for directory entry

The 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 that has caused some WebStart applications to fail to load.

See JDK-8184993

Bug Fixes

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

Java SE 8u141 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u141 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u141 b32

Please note that fixes from prior BPR (8u131 b34) are included in this version.

Known Issues

deploy/webstart

JAR file validation changes

After upgrading to the JDK July CPU release (8u141/7u151/6u161), when executing Java Webstart applications, customers may encounter an exception like

“java.lang.SecurityException: digest missing for …” that prevents the application from loading.

The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name: org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:

NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.

1. Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
2. Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
3. Remove the current signature files ( e.g.: rm -f META-INF/*.SF META-INF/*.RSA META-INF/*.DSA ).
4. Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).

NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.

5. Re-sign the JAR file.

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp91706

See JDK-8184993

Bug Fixes

Java™ SE Development Kit 8, Update 141 (JDK 8u141)

July 18, 2017

The full version string for this update release is 1.8.0_141-b15 (where "b" means "build"). The version number is 8u141.

IANA Data 2017b

JDK 8u141 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u141 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u141) will expire with the release of the next critical patch update scheduled for October 17, 2017.

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. For more information, see JRE Expiration Date.

Known Issues

deploy/webstart

JAR file validation changes

After upgrading to the JDK July CPU release (8u141/7u151/6u161), when executing Java Webstart applications, customers may encounter an exception like “java.lang.SecurityException: digest missing for …” that prevents the application from loading.

The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name: org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:

NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.

1. Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
2. Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
3. Remove the current signature files ( e.g.: rm -f META-INF/*.SF META-INF/*.RSA META-INF/*.DSA ).
4. Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).

NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.

5. Re-sign the JAR file.

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp91706

See JDK-8184993

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)

New Features

security-libs/java.security

Disable SHA-1 TLS Server Certificates

Any TLS server certificate chain containing a SHA-1 certificate (end-entity or intermediate CA) and anchored by a root CA certificate included by default in Oracle's JDK is now blocked by default. TLS Server certificate chains that are anchored by enterprise or private CAs are not affected. Only X.509 certificate chains that are validated by the PKIX implementation of the CertPathValidator and CertPathBuilder APIs and the SunX509 and PKIX implementations of the TrustManagerFactory API are subject to the restrictions. Third-party implementations of these APIs are directly responsible for enforcing their own restrictions.

To implement this restriction and provide more flexibility for configuring your own restrictions, additional features have been added to the jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms Security Properties in the java.security file, as follows:

• jdk.certpath.disabledAlgorithms:

  Three new constraints have been added to this Security Property:

  A new constraint named jdkCA, that when set, restricts the algorithm if it is used in a certificate chain that is anchored by a trust anchor that is pre-installed in the JDK cacerts keystore. This condition does not apply to certificate chains that are anchored by other certificates, including those that are subsequently added to the cacerts keystore. Also, note that the restriction does not apply to trust anchor certificates, since they are directly trusted.

  A new constraint named denyAfter, that when set, restricts the algorithm if it is used in a certificate chain after the specified date. The restriction does not apply to trust anchor certificates, since they are directly trusted. Also, code signing certificate chains as used in signed JARs are treated specially as follows:

  • if the certificate chain is used with a signed JAR that is not timestamped, it will be restricted after the specified date

  • if the certificate chain is used with a signed JAR that is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.

  A new constraint named usage, that when set, restricts the algorithm if it is used in a certificate chain for the specified use(s). Three usages are initially supported: TLSServer for TLS/SSL server certificate chains, TLSClient for TLS/SSL client certificate chains, and SignedJAR for certificate chains used with signed JARs.

Multiple constraints can be combined to constrain an algorithm when delimited by '&'. For example, to disable SHA-1 TLS Server certificate chains that are anchored by pre-installed root CAs, the constraint is "SHA1 jdkCA & usage TLSServer".

• jdk.jar.disabledAlgorithms:

  A new constraint has been added named denyAfter, that when set, restricts the algorithm if it is used in a signed JAR after the specified date, as follows:

  • if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date

  • if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.

  For example, to restrict SHA1 in JAR files signed after January 1st 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". The syntax is the same as the certpath property, however certificate checking will not be performed by this property.

See JDK-8176536

Changes

core-svc/java.lang.management

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)

security-libs/javax.net.ssl

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

xml/jax-ws

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)

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

Java SE 8u131 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u131 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u131 b34

Bug Fixes

Changes in Java SE 8u131 b33

Bug Fixes

Changes in Java SE 8u131 b32

Bug Fixes

Changes in Java SE 8u131 b31

Please note that fixes from prior BPR (8u121 b36) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 131 (JDK 8u131)

April 18, 2017

The full version string for this update release is 1.8.0_131-b11 (where "b" means "build"). The version number is 8u131.

IANA Data 2017a

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u131 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u131) will expire with the release of the next critical patch update scheduled for July 18, 2017.

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), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Changes

security-libs/java.security

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 that are run with a SecurityManager enabled and are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.

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)

core-libs/java.net

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 that 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 request 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 request, 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)

core-libs/java.net

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 request, 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)

tools/visualvm

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

Bug Fixes

The following are some of the notable bug fixes included in this release:

client-libs/java.awt

Introduced a 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 that 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

security-libs/javax.net.ssl

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

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

Java SE 8u121 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u121 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u121 b36

Bug Fixes

Changes in Java SE 8u121 b35

Bug Fixes

A regression has been identified with this build which impacts resource manager functionality only. This regression is only encountered if the commercial resource manager feature is turned on via: "-XX:+UnlockCommercialFeatures -XX:+ResourceManagement". JDK-8145826 (not public)

Changes in Java SE 8u121 b34

Bug Fixes

Changes in Java SE 8u121 b33

Bug Fixes

Changes in Java SE 8u121 b31

Please note that fixes from prior BPR (8u112 b32) are included in this version.

Bug Fixes

The fix made under JDK-8164476 does not take any effect without changes for JDK-8141054. JDK-8141054 will be included in the next JDK8u121 BPR build

Java™ SE Development Kit 8, Update 121 (JDK 8u121)

January 17, 2017

The full version string for this update release is 1.8.0_121-b13 (where "b" means "build"). The version number is 8u121.

IANA Data 2016i

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u121 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u121) will expire with the release of the next critical patch update scheduled for April 18, 2017.

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), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Notes

core-libs/javax.naming

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)

security-libs/java.security

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

New Features

security-libs/javax.xml.crypto

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

core-libs/java.io:serialization

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

core-libs/java.rmi

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)

security-libs

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

*New certpath constraint: jdkCA*

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

Changes

security-libs/javax.net.ssl

Make 3DES as a legacy algorithm in the JSSE provider

For SSL/TLS/DTLS protocols, the security strength of 3DES cipher suites is not sufficient for persistent connections. By adding 3DES_EDE_CBC to the jdk.tls.legacyAlgorithms security property by default in JDK, 3DES cipher suites will not be negotiated unless there are no other candidates during the establishing of SSL/TLS/DTLS connections.

At their own risk, applications can update this restriction in the security property (jdk.tls.legacyAlgorithms) if 3DES cipher suites are really preferred.

JDK-8165071 (not public)

security-libs/javax.net.ssl

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

tools/javadoc(tool)

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)

security-libs/javax.xml.crypto

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)

docs/release_notes

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)

security-libs

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)

core-libs/java.net

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)

Bug Fixes

The following are some of the notable bug fixes included in this release:

client-libs/javax.swing

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 (https://docs.oracle.com/javase/8/docs/api/java/awt/event/MouseWheelEvent.html#getWheelRotation):

"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

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

Known Issues

security-libs/javax.net.ssl

IllegalArgumentException from TLS handshake

A recent issue from the JDK-8148516 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

deploy/packager

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 sets where the JavaAppletPlugin.plugin for the desired JRE to bundle is located in the current directory.

See JDK-8166835

install/install

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)

Java SE 8u112 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u112 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u112 b32

Bug Fixes

Changes in Java SE 8u112 b31

Please note that fixes from prior BPR (8u102 b35) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 112 (JDK 8u112)

October 18, 2016

The full version string for this update release is 1.8.0_112-b15 (b16 for OS X) (where "b" means "build"). The version number is 8u112.

IANA Data 2016f

JDK 8u112 contains IANA time zone data version 2016f. For more information, refer to Timezone Data Versions in the JRE Software.
See JDK-8159684

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u112 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u112) will expire with the release of the next critical patch update scheduled for January 17, 2017.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u112) on February 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. For more information, see JRE Expiration Date.

Changes

security-libs/java.security
SunPKCS11 Provider no longer offering SecureRandom by default
SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg

Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation have allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method.
See JDK-8098581

Known Issues

deploy
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. To fix this problem, users can install JRE 8u112.
See JDK-8165867.

Bug Fixes

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

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

October 18, 2016

The full version string for this update release is 1.8.0_111-b14 (where "b" means "build"). The version number is 8u111.

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u111 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u111) will expire with the release of the next critical patch update scheduled for January 17, 2017.

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), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Certificate Changes

New 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)

Changes

client-libs/java.awt

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)

core-libs/java.net

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)

security-libs/java.security

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:

1. jar: beginEntry META-INF/my_sig.RSA
2. jar: processEntry: processing block
3. jar: processEntry caught: java.security.SignatureException: Signature check
4. failed. Disabled algorithm used: MD2withRSA
5. 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)

deploy

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

hotspot/jfr

Some events not available in JFR recordings on Windows

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

1. hotspot/jvm/os/processor/cpu_load
2. 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)

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

Java SE 8u102 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u102 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u102 b35

Bug Fixes

Changes in Java SE 8u102 b34

Bug Fixes

Changes in Java SE 8u102 b33

Bug Fixes

Changes in Java SE 8u102 b31

Please note that fixes from prior BPR (8u92 b34) are included in this version.

Bug Fixes

Java™ SE Development Kit 8, Update 102 (JDK 8u102)

July 19, 2016

The full version string for this update release is 1.8.0_102-b14 (where "b" means "build"). The version number is 8u102.

IANA Data 2016d

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

See JDK-8151876

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u102 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u102) will expire with the release of the next critical patch update scheduled for October 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u102) on November 19, 2016. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Notes

MSI Enterprise JRE Installer option, REMOVEOLDERJRES

MSI Enterprise JRE Installer option, REMOVEOLDERJRES, does not remove static installs. JDK-8161098 (not public)

Enhancements

security-libs/javax.net.ssl

Support SHA224withDSA and SHA256withDSA in the SunJSSE provider

The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions.

See JDK-8049321

core-libs/java.lang.invoke

Internal package sun.invoke.anon has been removed

The internal package sun.invoke.anon has been removed. The functionality it used to provide, namely anonymous class loading with possible constant pool patches, is available via the Unsafe.defineAnonymousClass() method.

See JDK-8081512

hotspot/runtime

New property jdk.lang.processReaperUseDefaultStackSize

When a large TLS (Thread local storage) size is set for Threads, the JVM results in a stack overflow exception. The reason for this behavior is that the reaper thread was created with a low stack size of 32768k. When a large TLS size is set, it steals space from the threads stack, which eventually results in a stack overflow. This is a known glibc bug. To overcome this issue, we have introduced a workaround (jdk.lang.processReaperUseDefaultStackSize) in which the user can set the reaper threads stack size to a default instead of to 32768. This gives the reaper thread a bigger stack size, so for a large TLS size, such as 32k, the process will not fail. Users can set this flag in one of two ways:

1. -Djdk.lang.processReaperUseDefaultStackSize=true
2. System.setProperty("jdk.lang.processReaperUseDefaultStackSize", "true")

The problem has been observed only when JVM is started from JNI code in which TLS is declared using "__thread"

See JDK-8130425

hotspot/compiler

Implemented performance improvements for BigInteger.montgomeryMultiply

We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture.

See JDK-8130150

New Features

deploy/webstart

32/64-bit interoperability in Java Web Start

The ability to specify a preference to launch a Java Web Start application in 64-bit or 32-bit architectures is now supported, by adding the 'arch' attribute to the JNLP resources block.

See JDK-8147627

core-libs

Ability to limit the capacity of buffers that can be held in the temporary buffer cache

The system property jdk.nio.maxCachedBufferSize has been introduced in 8u102 to limit the memory used by the "temporary buffer cache." The temporary buffer cache is a per-thread cache of direct memory used by the NIO implementation to support applications that do I/O with buffers backed by arrays in the java heap. The value of the property is the maximum capacity of a direct buffer that can be cached. If the property is not set, then no limit is put on the size of buffers that are cached. Applications with certain patterns of I/O usage may benefit from using this property. In particular, an application that does I/O with large multi-megabyte buffers at startup but does I/O with small buffers may see a benefit to using this property. Applications that do I/O using direct buffers will not see any benefit to using this system property.

See JDK-8147468

core-svc/java.lang.management

New system property for the remote JMX connector

*New JMX agent property - jmxremote.host* A new property, com.sun.management.jmxremote.host, is introduced that specifies the bind address for the default JMX agent. If the latter is not specified, the default JMX agent will listen on all interfaces (0.0.0.0) and the host value placed in the agent service URL (JMXServiceURL) is the IP address returned from invocation of the InetAddress.getLocalHost() method.

• Name:

  com.sun.management.jmxremote.host

• Definition:

  Specifies bind address for default JMX agent. It can be specified via command line while starting JVM or as part of agent config file (management.properties).

• Value:

  IP address of any network interface of the machine

See JDK-6425769

Changes

javafx/web

Fixed memory leak when Java objects are passed into JavaScript

The bug fix for JDK-8089861, which was first integrated in JDK 8u102, fixes a memory leak when Java objects are passed into JavaScript. Prior to JDK 8u102, the WebView JavaScript runtime held a strong reference to such bound objects, which prevented them from being garbage collected. After the fix for JDK-8089861, the WebView JavaScript runtime uses weak references to refer to bound Java objects. The specification was updated to make it clear that this is the intended behavior. Applications which rely on the previously unspecified behavior might be affected by the updated behavior if the application does not hold a strong reference to an object passed to JavaScript. In such case, the Java object might be garbage collected prematurely. The solution is to modify the application to hold a strong reference in Java code for objects that should remain live after being passed into JavaScript.

See JDK-8089681

security-libs/javax.net.ssl

Modify requirements on Authority Key Identifier extension field during X509 certificate chain building

The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases.

See JDK-8072463

hotspot/gc

Providing more granular levels for GC verification

This enhancement provides a way to specify more granular levels for the GC verification enabled using the VerifyBeforeGC, VerifyAfterGC, and VerifyDuringGC diagnostic options. It introduces a new diagnostic option VerifySubSet with which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap, and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified:

    D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test
[0.095s][debug ][gc,verify] Threads
[0.099s][debug ][gc,verify] C-heap
[0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms
[0.120s][debug ][gc,verify] Threads
[0.124s][debug ][gc,verify] C-heap
[0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms
[0.148s][debug ][gc,verify] Threads
[0.152s][debug ][gc,verify] C-heap 
        

If any invalid memory sub-systems are specified with VerifySubSet, the Java process exits with the following error message:

D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom
Error occurred during initialization of VM
VerifySubSet: 'hello' memory sub-system is unknown, please correct it 
        

See JDK-8072725

hotspot/compiler

Removed PICL warning message

In 8u40 and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed.

See JDK-8144957

core-libs/javax.naming

Improved exception handling for bad LDAP referral replies

The JDK was throwing a NullPointerException when a non-compliant REFERRAL status result was sent but no referral values were included. With this change, a NamingException with message value of "Illegal encoding: referral is empty" will be thrown in such circumstances.

See JDK-8149450 and JDK-8154304

Bug Fixes

client-libs
.oracle_jre_usage folder is no longer created in C\Users\myName
Since JDK 1.8.0_60, a folder named .oracle_jre_usage is created in the home directory. This folder and the files inside it are created by the Java Runtime Environment to track the last time a JRE was used. This information is very important in understanding what JRE installations are currently being used on the system.
On Windows, this folder was created under either C:\Users\\AppData\Local or C:\Users\myName\AppData\Roaming depending upon whether the user is local, or is a network user.
Writing content in this folder over the network on Windows can introduce performance overhead. This problem has been fixed with JDK-8134300. With this fix, the .oracle_jre_usage folder is created under %ProgramData%/Oracle/Java/.

See JDK-8134300

security-libs/javax.net.ssl

Fix to resolve "Unable to process PreMasterSecret, may be too big" issue

Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big

See JDK-8149017

hotspot/gc

With UseG1GC, specifying -XX:ParallelGCThreads=0 is no longer allowed

With UseG1GC, specifying -XX:ParallelGCThreads=0 is no longer allowed. Previously, with -XX:ParallelGCThreads=0, G1 would execute some tasks using serial code executed by the VM thread. The closest approximation of this behavior is to specify -XX:ParallelGCThreads=1, which causes parallel tasks to be executed by a single GC worker thread using parallel code.

See JDK-8150518

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

Java™ SE Development Kit 8, Update 101 (JDK 8u101)

July 19, 2016

The full version string for this update release is 1.8.0_101-b13 (where "b" means "build"). The version number is 8u101.

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

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u101 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u101) will expire with the release of the next critical patch update scheduled for October 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u101) on November 19, 2016. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Certificate Changes

New DTrust certificates added to root CAs

Two new root certificates have been added:

1. D-TRUST Root Class 3 CA 2 2009
2. alias: dtrustclass3ca2
3. DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
4. D-TRUST Root Class 3 CA 2 EV 2009
5. alias: dtrustclass3ca2ev
6. DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE

See JDK-8153080

New IdenTrust certificates added to root CAs

Three new root certificates have been added:

1. IdenTrust Public Sector Root CA 1
2. alias: identrustpublicca
3. DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
4. IdenTrust Commercial Root CA 1
5. alias: identrustcommercial
6. DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
7. IdenTrust DST Root CA X3
8. alias: identrustdstx3
9. 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

Changes

other-libs/corba

Improve access control to javax.rmi.CORBA.ValueHandler

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

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

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

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

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

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

JDK-8079718 (not public)

security-libs/java.security

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

security-libs/javax.crypto

MSCAPI KeyStore can handle same-named certificates

Java SE KeyStore does not allow certificates that have the same aliases (http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html).

However, on Windows, multiple certificates stored in one keystore are allowed to have non-unique friendly names. The fix for JDK-6483657 makes it possible to operate on such non-uniquely named certificates through the Java API by artificially making the visible aliases unique.

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

It is still recommended that your design not use multiple certificates with the same name. In particular, the following sentence will not be removed from the Java documentation: "In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case."

(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html)

See JDK-6483657

security-libs/java.security

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

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

JDK-8147771 (not public)

Bug Fixes

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

Known Issues

deploy

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 dialogue 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, Dec 2005) per http://www.oracle.com/java/technologies/javase/family-clsid.html.

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

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

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

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

JDK-8147457 (not public)

Java SE 8u92 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 8u92 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

Changes in Java SE 8u92 b34

Bug Fixes