No results found

Your search did not match any results.

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

  • Check the spelling of your keyword search.
  • Use synonyms for the keyword you typed, for example, try “application” instead of “software.”
  • Try one of the popular searches shown below.
  • Start a new search.
Trending Questions
java

Release Notes for JDK 8 and JDK 8 Update Releases

This page contains all of the release notes for General Availability (GA) releases and Bundled Patch Release (BPR) builds of JDK 8.

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.

Cumulative Release Notes for JDK 8 and JDK 8 Update Releases

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

BugId Category Subcategory Description
8252789 deploy deployment_toolkit Empty client certificate issue during TLS handshake
8249183 client-libs java.awt JVM crash in "AwtFrame::WmSize" method
8249846 core-libs java.util.concurrent Change of behavior after JDK-8237117: Better ForkJoinPool behavior
8252861 deploy Disable TLSv1.3 by default on deploy configurations

Changes in Java SE 8u261 b34

Bug Fixes

BugId Category Subcategory Description
8247839 javafx graphics Wrong position of GUI elements using multiple HiDPI displays in JavaFX 8
8193800 javafx controls TreeTableView selection changes on sorting

Changes in Java SE 8u261 b33

Bug Fixes

BugId Category Subcategory Description
8248505 security-libs java.security Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider
8248990 (Confidential) docs guides Remove link to old license page from JDK 8 troubleshooting guide
8248523 (Confidential) docs guides In TLS overview page, change JDK 11 to JDK 8
8235932 (Confidential) docs guides Backport TLS 1.3 documentation for JDK 8u MR3
8245624 (Confidential) embedded hotspot Arm support missing for JDK-8176100
8062947 core-libs javax.naming Fix exception message to correctly represent LDAP connection failure
8217606 core-libs javax.naming LdapContext#reconnect always opens a new connection
8151678 core-libs javax.naming com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect
8243138 core-libs javax.naming Enhance BaseLdapServer to support starttls extended request
8247925 (Confidential) xml jaxp JDK8u251- XSL transformer fails with TransformerConfigurationException

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:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_261-b12
7 1.7.0_271-b10

Keeping the JDK up to Date

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

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 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

hotspot/runtime
JDK/JRE Runtime Windows Visual Studio Library (DLL) Dependency Changes

As part of ongoing maintenance, the Microsoft Visual Studio 2017 tool chain will be used to build JDK 7 and JDK 8 for Windows. JDK 8u261, in the July 2020 CPU, was built with Visual Studio 2017. With the release of the October 2020 CPU, JDK 7u281 will move to Visual Studio 2017.

Moving to Visual Studio 2017 for JDK 7 and JDK 8 requires changing the runtime library that the JDK/JRE depends on. Before this change, JDK/JRE implementations used and shipped the Microsoft Visual C++ 2010 SP1 Redistributable Package (x86/x64) that included MSVCR100.dll [a][b]. Microsoft Visual Studio 2017 uses a different set of libraries/DLLs.

Native applications (including JNI) that have depended on and assumed the presence of MSCVR100.dll in the JDK/JRE directory will fail to run. When this happens, users will see an error such as:

"The code execution cannot proceed because MSVCR100.dll was not found. Reinstalling the program may fix this problem."

These applications should be rebuilt and shipped with modern C++ runtime dependencies that use a later instance of Visual Studio. Applications should not depend on DLLs included with the JDK/JRE that are not documented in the product as offering support for the specification or other functionality in Java SE.

[a] http://support.microsoft.com/kb/2019667

[b] https://docs.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2020

JDK-8246783 (not public)

security-libs/javax.net.ssl
JEP 332 Transport Layer Security (TLS) 1.3

JDK 8u261 includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the Java Secure Socket Extension (JSSE) Reference Guide documentation and JEP 332.

For TLS 1.3, the following new standard algorithm names are defined:

  • TLS protocol version name: TLSv1.3
  • SSLContext algorithm name: TLSv1.3
  • TLS cipher suite names for TLS 1.3: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384

TLS 1.3 is disabled for default SSLContext("SSL" or "TLS") for client end-point.

The TLS 1.3 protocol can be enabled using several mechanisms already available in the JDK. For example, TLS 1.3 protocol can be enabled on SSL/TLS connections using SSLSocket/SSLEngine/SSLServerSocket APIs and system properties by one of the following:

  1. sslSocket.setEnabledProtocols(new String[] { "TLSv1.3", "TLSv1.2"});
  2. Setting up and using a TLSv1.3 based SSLContext : SSLContext ctx = SSLContext.getInstance("TLSv1.3");
  3. Using the SSLParameters API: sslParameters.setProtocols(new String[] {"TLSv1.3", "TLSv1.2"});
  4. The jdk.tls.client.protocols system property can also be used to control the protocols in use for a TLS connection. One may launch their application with this property. For example, java -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2" enables TLSv1.3 and TLSv1.2 on client SSLSockets.
  5. The https.protocols system property can also be used to control the protocols on connection obtained through use of the HttpsURLConnection class or URL.openStream() operations. For example, -Dhttps.protocols=TLSv1.3,TLSv1.2.

A new system property, jdk.tls.server.protocols, has been added to configure the default enabled protocol suite in the server side of the SunJSSE provider.

A new security property, jdk.tls.keyLimits, has been added for TLS 1.3. When the specified amount of data of a specific algorithm has been processed, a post-handshake Key and IV Update is triggered to derive new keys.

Note that TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to take into account when upgrading to TLS 1.3:

  • TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions use a duplex-close policy. For applications that depend on the duplex-close policy, there might be compatibility issues when upgrading to TLS 1.3. A new system property, jdk.tls.acknowledgeCloseNotify, is added. The default value of the system property is "false". If the system property is set to "true", a corresponding close_notify alert will be sent when receiving a close_notify alert, and the connection will be duplex closed.
  • The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application can use unsupported signature algorithms.
  • The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot upgrade to TLS 1.3.
  • The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and prior versions. If an application hard-codes cipher suites that are no longer supported, it cannot use TLS 1.3 without modifying the application code.
  • The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility impact should be minimal; however, there could be a risk if an application depends on the handshake details of the TLS protocols.
  • The legacy com.sun.net.ssl.dhKeyExchangeFix system property has been removed from the new TLS implementation.

Improved JSSE debug logging format has been introduced to record the logger name, the logger level, the thread ID, the thread name, the time and the caller for each log item. Use the javax.net.debug=all system property to get full debug logs.

See JDK-8145252

security-libs/javax.crypto
 JCE Jurisdiction Policy Files updated

Since January 2018 (8u161, 7u171) unlimited Java Cryptography Extension (JCE) Jurisdiction Policy files have been bundled with the JDK and enabled by default (see JDK Cryptographic Roadmap).

The certificate for the old stand alone jar has expired, and if used the following exception will be seen:

Caused By: java.lang.SecurityException: The jurisdiction policy files are not signed by the expected signer! (Policy files are specific per major JDK release.Ensure the correct version is installed.) at javax.crypto.JarVerifier.verifyPolicySigned(JarVerifier.java:336) at
javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:378) at
javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:323) at
javax.crypto.JceSecurity.access$000(JceSecurity.java:50) at
javax.crypto.JceSecurity$1.run(JceSecurity.java:85) at java.security.AccessController.doPrivileged(Native Method) at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:82)

If still required for older releases the re-signed files can be found at https://www.oracle.com/java/technologies/oracle-java-archive-downloads.html

JDK-8245319 (not public)

security-libs/javax.net.ssl
New System Properties to Configure the TLS Signature Schemes

Two new System Properties are added to customize the TLS signature schemes in JDK. jdk.tls.client.SignatureSchemes is added for TLS client side, and jdk.tls.server.SignatureSchemes is added for server side.

Each System Property contains a comma-separated list of supported signature scheme names specifying the signature schemes that could be used for the TLS connections.

The names are described in the "Signature Schemes" section of the Java Security Standard Algorithm Names Specification.

See JDK-8242141

security-libs/javax.net.ssl
Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS

The JDK SunJSSE implementation now supports the TLS FFDHE mechanisms defined in RFC 7919. If a server cannot process the supported_groups TLS extension or the named groups in the extension, applications can either customize the supported group names with jdk.tls.namedGroups, or turn off the FFDHE mechanisms by setting the System Property jsse.enableFFDHE to false.

See JDK-8140436

infrastructure
Toolchain Upgrade to Xcode 10.1

Build Environment Update for macOS Moved to Xcode 10.1 On macOS, the toolchain used to build the JDK has been upgraded from Xcode 4.5 to Xcode 10.1.

JDK-8232007 (not public)

Removed Features and Options

security-libs/java.security
Removal of Comodo Root CA Certificate

The following expired Comodo root CA certificate was removed from the cacerts keystore:

  • alias name "addtrustclass1ca [jdk]"

    Distinguished Name: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE

See JDK-8225069

security-libs/java.security
Removal of DocuSign Root CA Certificate

The following expired DocuSign root CA certificate was removed from the cacerts keystore:

  • alias name "keynectisrootca [jdk]"

    Distinguished Name: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR

See JDK-8225068

Other notes

javafx/media
Media Playback Does Not Work on Ubuntu 20.04

Media playback does not work on Ubuntu 20.04. This affects all media formats (such as, mp4, mp3, wav, etc.). In some cases, an error will be thrown. In other cases, the media player will switch to the ready state, but playback will not start. There is no workaround for this issue. This issue should be resolved by JDK-8239095.

JDK-8245501 (not public)

core-libs/java.util:collections
Better Listing of Arrays

The preferred way to copy a collection is to use a "copy constructor." For example, to copy a collection into a new ArrayList, one would write new ArrayList<>(collection). In certain circumstances, an additional, temporary copy of the collection's contents might be made in order to improve robustness. If the collection being copied is exceptionally large, then the application should be (aware of/monitor) the significant resources required involved in making the copy.

JDK-8231800 (not public)

install/install
Java Mission Control Is No Longer Bundled With the JDK

This version of the JDK no longer includes Java Mission Control (JMC). The jmc launcher has been removed from the JDK bin directory, and the missioncontrol directory has been removed from the JDK lib directory. The .jfr file association is not registered by JDK installers. JMC is now available as a separate download. Please visit https://www.oracle.com/javase/jmc for more information.

JDK-8244662 (not public)

deploy/plugin
Possible Hang of Internet Explorer 11 With JDK 8u261 on Windows 7

On Windows 7, the Internet Explorer 11 (IE 11) JavaScript engine does not interact properly with Java Applets because, beginning with 8u261, the JDK/JRE is compiled with VisualStudio 2017. For example, an application that uses the JavaScript methods setTimeout() and setInterval() may cause IE 11 to hang when a modal dialog is shown by a Java Applet.

JDK-8244937 (not public)

core-svc/java.lang.management
OperatingSystemMXBean Methods Inside a Container Return Container Specific Data

When executing in a container, or other virtualized operating environment, the following OperatingSystemMXBean methods in this release return container specific information, if available. Otherwise, they return host specific data:

  • getFreePhysicalMemorySize()
  • getTotalPhysicalMemorySize()
  • getFreeSwapSpaceSize()
  • getTotalSwapSpaceSize()
  • getSystemCpuLoad()

See JDK-8226575

security-libs
Default SSL Session Cache Size Updated to 20480

The default SSL session cache size has been updated to 20480 in this JDK release

See JDK-8210985

security-libs/javax.net.ssl
BoringSSL Rejects JSSE TLS 1.3 HTTPS Connections When status_request Extension Is Disabled

BoringSSL is an SSL library deployed on some popular websites such as those run by Google/YouTube. An interoperability issue with the BoringSSL library can lead to a connection failure if TLSv1.3 is presented as the only enabled protocol in the ClientHello message and the certificate status_request extension is disabled. Enabling the certificate status_request extension by setting the jdk.tls.client.enableStatusRequestExtension system property to true will provide mitigation in such scenarios.

See JDK-8241360

security-libs/javax.net.ssl
Increase the priorities of GCM cipher suites

In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider.

In the SunJSSE provider, the following ciphersuites are now the most preferred by default:


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

Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases.

See JDK-8028518

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

BugId Category Subcategory Description
8244579 javafx web Windows "User Objects" leakage with WebView

Changes in Java SE 8u251 b35

Bug Fixes

BugId Category Subcategory Description
8242884 deploy plugin 8u241 32 bit SSV Helper causes long load time and page load on IE11
8151788 core-libs java.net NullPointerException from ntlm.Client.type3
8210147 core-libs java.net adjust some WSAGetLastError usages in windows network coding

Changes in Java SE 8u251 b34

Bug Fixes

BugId Category Subcategory Description
8241966 (Confidential) install Add Oracle copyright to modified Sparkle 1.23.0 files
8241965 (Confidential) install Update THIRD_PARTY_README for Sparkle 1.23.0
8241814 (Confidential) install auto_update [macos] 8u251b60 AU missing "Remind Me" button
8241410 (Confidential) infrastructure 8u251 b60 Mac notarized build is missing the ant-javafx.jar
8241399 (Confidential) client-libs java.awt jdk8 build broken on macOS 10.7 and sdk 10.8
8240780 infrastructure build[8u] update jprt.properties to add Xcode 10.1 / macOS 10.13 builds
8239919 hotspot [8u] enable parentheses-equality warnings in HotSpot
8239808 (Confidential) install auto_update Change URL In <cntry-lookup> Tag In mac-XXX-XX.xml
8239400 hotspot [8u] clean up delete-non-virtual-dtor warnings in HotSpot
8239223 hotspot [8u] enable Wparentheses warnings in HotSpot
8239112 hotspot [8u] clean up empty-body warnings in HotSpot
8239053 hotspot runtime [8u] clean up undefined-var-template warnings
8238852 (Confidential) install install [macos] AU to NEXTVER failed when AU from 8u251 to future
8238700 (Confidential) infrastructure build Signing reliability change not fully working on 8u
8238225 infrastructure build Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary
8237820 infrastructure build remove clang version check for optimization bug workaround from 8u
8236971 javafx window-toolkit [macos] Gestures handled incorrectly due to missing events
8236956 (Confidential) security-libs javax.net.ssl Backport test lib files from JDK-8228967
8235687 infrastructure build Contents/MacOS/libjli.dylib cannot be a symlink
8232580 (Confidential) infrastructure build Sign Macosx binaries with hardened runtime enabled
8232087 (Confidential) security-libs org.ietf.jgss Migrate KDC from sca00jvo/burge0401/sca00kte/sca00lol/adc1140258/sca00joh to new OCI hosts
8231438 client-libs java.awt [macOS] Dark mode for the desktop is not supported
8231092 (Confidential) infrastructure build Implement Apple notarization support in the build
8230555 (Confidential) security-libs javax.net.ssl OCI migration on IIS
8226306 (Confidential) infrastructure build Improve signing reliability
8214046 client-libs java.awt [macosx] Undecorated Frame does not Iconify when set to
8213838 (Confidential) install Upgrade sparkle to 1.23.0
8202393 javafx media App Transport Security blocks http media on macOS with JDK build using new compilers
8200550 hotspot gc Xcode 9.3 produce warning -Wexpansion-to-defined
8196724 infrastructure build Change macosx deployment target to 10.9
8196538 (Confidential) infrastructure build Fix compilation errors when using Xcode 9.2/Macosx 10.13 in deploy and install
8181872 hotspot compiler C1: possible overflow when strength reducing integer multiply by constant
8152856 hotspot runtime Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X
8141056 hotspot gc Erroneous assignment in HeapRegionSet.cpp
8060721 hotspot runtime Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler
8043646 client-libs java.awt libosxapp.dylib fails to build on Mac OS 10.9 with clang
8030680 hotspot compiler 292 cleanup from default method code assessment
7188942 (Confidential) client-libs 2d Remove support of pbuffers in OGL Java2d pipeline

Changes in Java SE 8u251 b33

Bug Fixes

BugId Category Subcategory Description
8239444 (Confidential) security-libs java.security High contention java.security.Provider.getService()-JDK-7092821
7092821 security-libs java.security java.security.Provider.getService() is synchronized and became scalability bottleneck
8231387 security-libs java.security java.security.Provider.getService returns random result due to race condition with mutating methods in the same class
8228613 security-libs java.security java.security.Provider#getServices order is no longer deterministic
8239946 (Confidential) security-libs javax.crypto Update JarVerifier class with new signing cert details
8240439 (Confidential) core-libs java.net java.net.PlainDatagramSocketImpl.receive0 seems to fail for UDP traffic spontaneously

Changes in Java SE 8u251 b32

Bug Fixes

BugId Category Subcategory Description
8240694 javafx media [macos 10.15] JavaFX Media hangs on some video files on Catalina
8241629 javafx media Long startup delay playing media over https on Catalina
8176100 hotspot gc [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles

Changes in Java SE 8u251 b31

Bug Fixes

BugId Category Subcategory Description
8231779 hotspot gc crash HeapWord*ParallelScavengeHeap::failed_mem_allocate

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:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_251-b08
7 1.7.0_261-b07

Keeping the JDK up to Date

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

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 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.

See JDK-8051498

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

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

See JDK-8205445

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.

See JDK-8146293

 

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

JDK-8236798 (not public)

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

See JDK-8236645

 

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

BugId Category Subcategory Description
8163251 security-libs javax.smartcardio Hard coded loop limit prevents reading of smart card data greater than 8k
8236645 security-libs javax.xml.crypto JDK 8u231 introduces a regression with incompatible handling of XML messages
8239033 (Confidential) security-libs javax.xml.crypto Oracle JDK 8u Base64XmlEncode.java test fails for windows platform
8236832 javafx media [macos 10.15] JavaFX Application hangs on video play on Catalina
8239803 (Confidential) javafx build [macOS 10.15] Wrong SDK recorded in dylib files prevents notarization
8160768 core-libs javax.naming Add capability to custom resolve host/domain names within the default JNDI LDAP provider

Changes in Java SE 8u241 b32

Bug Fixes

BugId Category Subcategory Description
8234468 security-libs java.security Application startup failed on JRE 8u231

Changes in Java SE 8u241 b31

Bug Fixes

BugId Category Subcategory Description
8193445 javafx controls JavaFX CSS is applied redundantly leading to significant performance degradation

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:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_241-b07
7 1.7.0_251-b08

Keeping the JDK up to Date

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

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 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.

See JDK-8200400

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.

See JDK-8080462

 

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.

JDK-8230318 (not public)

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.

JDK-8227758 (not public)

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

See JDK-8232019

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

See JDK-8233223

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.

JDK-8230967 (not public)

 

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.

See JDK-8209672

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.

JDK-8231422 (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 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

BugId Category Subcategory Description
8223158 client-libs javax.swing Docked MacBook cannot start any Java Swing applications
8134424 core-libs java.io:serialization BlockDataInputStream.readUTFBody: size local StringBuffer with the given length
8077707
(Confidential)
client-libs javax.accessibility jdk9 b58 cannot run any graphical application on Win 8 with JAWS running

Changes in Java SE 8u231 b33

Bug Fixes

BugId Category Subcategory Description
8185538 client-libs 2d JDK 9 is really slow initialising some OTF/CFF fonts.
8223490 core-libs java.util Optimize search algorithm for determining default time zone
8209672
(Confidential)
client-libs 2d Oracle JDK 8 equivalent fix for JDK-8188030: AIOOBE in font manager init
8080465
(Confidential)
client-libs   The underline of the text doesn't display unless resizing the window with the option "-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".

Changes in Java SE 8u231 b32

Bug Fixes

BugId Category Subcategory Description
8230085 core-libs java.nio (fs) FileStore::isReadOnly is always true on macOS Catalina
8146238 client-libs 2d [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts
8230303 core-svc debugger JDB hangs when running monitor command

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:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_231-b11
7 1.7.0_241-b09

Keeping the JDK up to Date

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

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 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.

JDK-8223269 (not public)

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

See JDK-8148188

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.

See JDK-8187147

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

See JDK-8222496

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.

JDK-8230057 (not public)

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

JDK-8228825 (not public)

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.

See JDK-8177334

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.

See JDK-8177334

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.

JDK-8224499 (not public)

core-libs/java.lang
 Runtime.exec and ProcessBuilder Argument Restrictions 

Runtime.exec and ProcessBuilder have been updated in this release to tighten the constraints on the quoting of arguments to processes created by these APIs. The changes may impact applications on Microsoft Windows that are deployed with a security manager. The changes have no impact on applications that are run without a security manager.

In applications where there is no security manager, there is no change in the default behavior and the new restrictions are opt-in. To enable the restrictions, set the system property jdk.lang.Process.allowAmbiguousCommands to false.

In applications where there is a security manager, the new restrictions are opt-out. To revert to the previous behavior set the system property jdk.lang.Process.allowAmbiguousCommands to true.

Applications using Runtime.exec or ProcessBuilder with a security manager to invoke .bat or .cmd and command names that do not end in ".exe" may be more restrictive in the characters accepted for arguments if they contain double-quote, "&", "|", "<", ">", or "^". The arguments passed to applications may be quoted differently than in previous versions.

For .exe programs, embedded double quotes are allowed and are encoded so they are passed to Windows as literal quotes. In the case where the entire argument has been passed with quotes or must be quoted to encode special characters including space and tab, the encoding ensures they are passed to the application correctly. The restrictions are enforced if there is a security manager and the jdk.lang.Process.allowAmbiguousCommands property is "false" or there is no security manager and property is not "false".

JDK-8221858 (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 8u231 Bug Fixes page.

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

BugId Category Subcategory Description
8221246 client-libs java.awt NullPointerException within Win32ShellFolder2

Changes in Java SE 8u221 b35

Bug Fixes

BugId Category Subcategory Description
8080157 hotspot compiler assert(allocates2(pc)) failed: not in CodeBuffer memory
8130341 hotspot compiler GHASH 32bit intrinsics has AEADBadTagException
8073108 security-libs javax.crypto Use x86 and SPARC CPU instructions for GHASH acceleration
8048556 hotspot gc Unnecessary GCLocker-initiated young GCs

Changes in Java SE 8u221 b34

Bug Fixes

BugId Category Subcategory Description
8226895
(Confidential)
xml jaxp Problems when validating XML with STax

Changes in Java SE 8u221 b33

Bug Fixes

BugId Category Subcategory Description
8226543 security-libs javax.crypto Reduce GC pressure during message digest calculations in password-based encryption
8139965 core-libs javax.naming Hang seen when using com.sun.jndi.ldap.search.replyQueueSize
8225615
(Confidential)
deploy packager Need javapackager to work with Inno Setup 6.x
8223727
(Confidential)
core-libs javax.naming com/sun/jndi/ldap/privconn/RunTest.java failed due to hang in LdapRequest.getReplyBer

Changes in Java SE 8u221 b32

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

Bug Fixes

BugId Category Subcategory Description
8219914 client-libs   Change the environment variable for Java Access Bridge logging to have a directory
8196681 client-libs javax.accessibility Java Access Bridge logging and debug flags dynamically controlled

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_221-b11
7 1.7.0_231-b08

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

BugId Category Subcategory Description
8208666 client-libs 2d Missing glyphs from custom made font when rendering on Graphics2D
8178870 hotspot jvmti instrumentation.retransformClasses cause coredump
8155951 hotspot jvmti VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool
8151066 hotspot jvmti assert(0 <= i && i < length()) failed: index out of bounds
8221986
(Confidential)
javafx build Intermittent FX Hudson build failure on Windows: cannot execute gperf

Changes in Java SE 8u212 b33

Bug Fixes

BugId Category Subcategory Description
8218674 client-libs javax.swing HTML Tooltip with "img src=" on component doesn't show
8223233
(Confidential)
install install 8u 211 32 bit MSI uninstalls Java 8u211 64 bit, which is above the security baseline

Changes in Java SE 8u212 b32

Bug Fixes

BugId Category Subcategory Description
8204060 javafx graphics [Canvas] Add API in GraphicsContext to control image smoothing
8221263 client-libs 2d [TEST_BUG] RemotePrinterStatusRefresh test is hard to use
8153732 client-libs 2d Windows remote printer changes do not reflect in lookupPrintServices()
8221412 client-libs 2d lookupPrintServices() does not always update the list of Windows remote printers
8212202 client-libs 2d [Windows] Exception if no printers are installed.
8194653 core-libs java.lang Deadlock involving FileSystems.getDefault and System.loadLibrary call
8219410
(Confidential)
javafx graphics [GraphicsContext] Backport doc changes

Changes in Java SE 8u212 b31

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

Bug Fixes

BugId Category Subcategory Description
8221355 hotspot compiler Performance regression after JDK-8155635 backport into 8u

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_211-b12
7 1.7.0_221-b08
6 1.6.0_221

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_211-b12
7 1.7.0_221-b08
6 1.6.0_221

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

Distinguished Name SHA-256 Fingerprint
CN=GeoTrust Global CA, O=GeoTrust Inc., C=US

FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA: DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A

CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US

37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8: 2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C

CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US

5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F: 7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66

CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US

B4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E: E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4

CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US

A0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93: 42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12

CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US

8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A: 97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F

CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US

A4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB: 43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57

CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US

4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C: 06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C

EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47: 9C:36:93:65:08:80:50:56:98:10:5D:BC:E9

OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F: D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1

OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09: CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05

OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E: DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B

CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

EB:04:CF:5E:B1:F3:9A:FA:76:2F:2B:B1:20:F2:96:CB:A5:20:C1: B9:7D:B1:58:95:65:B8:1C:B9:A1:7B:72:44

CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

69:DD:D7:EA:90:BB:57:C9:3E:13:5D:C8:5E:A6:FC:D5:48:0B:60: 32:39:BD:C4:54:FC:75:8B:2A:26:CF:7F:79

CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

9A:CF:AB:7E:43:C8:D8:80:D0:6B:26:2A:94:DE:EE:E4:B4:65:99: 89:C3:D0:CA:F1:9B:AF:64:05:E4:1A:B7:DF

CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5: C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C

Subordinate Certificates distrusted after 2019-12-31

Distinguished Name SHA-256 Fingerprint
CN=Apple IST CA 2 - G1, OU=Certification Authority, O=Apple Inc., C=US

AC:2B:92:2E:CF:D5:E0:17:11:77:2F:EA:8E:D3:72:DE:9D:1E:22:45:FC:E3:F5:7A: 9C:DB:EC:77:29:6A:42:4B

CN=Apple IST CA 8 - G1, OU=Certification Authority, O=Apple Inc., C=US

A4:FE:7C:7F:15:15:5F:3F:0A:EF:7A:AA:83:CF:6E:06:DE:B9:7C:A3:F9:09:DF:92:0A: C1:49:08:82:D4:88:ED

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

 Support New Japanese Era in java.time.chrono.JapaneseEra 

The JapaneseEra class and its of(int), valueOf(String), and values() methods are clarified to accommodate future Japanese era additions, such as how the singleton instances are defined, what the associated integer era values are, etc.

See JDK-8212941

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

BugId Category Subcategory Description
8204142 client-libs java.awt AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts.
8217227
(Confidential)
deploy plugin Java Deployment Ruleset (DRS) not working for forms Web Start (webstart) configÂ
8221544
(Confidential)
deploy webstart StackOverflowError and JWS fails to launch for some client PCs in cluster config

Changes in Java SE 8u202 b32

Bug Fixes

BugId Category Subcategory Description
8213583 client-libs java.awt Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files
8207070 client-libs java.awt Webstart app popup on wrong screen in a one-screen setup changing to multi-monitor
8027434 hotspot runtime "-XX:OnOutOfMemoryError" uses fork instead of vfork

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_201-b09
7 1.7.0_211-b07
6 1.6.0_221

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_201-b09
7 1.7.0_211-b07
6 1.6.0_221

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

BugId Category Subcategory Description
8213011 deploy plugin Running application under 1.8u172 via a DRS rules with the 1.8u192 plugin fail with java.lang.NoSuchMethodError
8187364 client-libs javax.swing Unable to enter zero width non-joiner (ZWNJ) symbol in Swing text component
8159886 deploy plugin Window of a newly launched Oracle Forms applet loses focus
8141491 core-libs java.nio Unaligned memory access in Bits.c
8029661 security-libs javax.net.ssl Support TLS v1.2 algorithm in SunPKCS11 provider
8129988 security-libs javax.net.ssl JSSE should create a single instance of the cacerts KeyStore
8203190 security-libs javax.net.ssl SessionId.hashCode generates too many collisions

Changes in Java SE 8u192 b33

Bug Fixes

BugId Category Subcategory Description
8212457 deploy webstart JWS: Application does not launch on when jnlp.delete.jnlp.file is enabled

Changes in Java SE 8u192 b32

Bug Fixes

BugId Category Subcategory Description
8139507 core-libs java.util WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs
8170937 client-libs java.awt Swing apps are slow if displaying from a remote source to many local displays
8193879
(Confidential)
core-svc debugger Java debugger hangs on method invocation
8163083
(Confidential)
core-svc debugger SocketListeningConnector does not allow invocations with port 0

Changes in Java SE 8u192 b31

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

Bug Fixes

BugId Category Subcategory Description
8208638 client-libs javax.swing Instead of circle rendered in appl window, but ellipse is produced JEditor Pane

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_191-b12
7 1.7.0_201-b11
6 1.6.0_211-b11

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

security-libs/javax.net.ssl

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_191-b12
7 1.7.0_201-b11
6 1.6.0_211-b11

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

BugId Category Subcategory Description
8211107 core-libs javax.naming LDAPS communication failure with jdk 1.8.0_181

Changes in Java SE 8u181 b36

Bug Fixes

BugId Category Subcategory Description
8204513
(Confidential)
deploy deployment_toolkit Context lost after resizing the browser window in applet with Forms

Changes in Java SE 8u181 b35

Bug Fixes

BugId Category Subcategory Description
8201818 client-libs 2d [macosx] Printing attributes break page size set via "java.awt.print.Book" object

Changes in Java SE 8u181 b34

Bug Fixes

BugId Category Subcategory Description
8208583 security-libs javax.crypto Better management of internal KeyStore buffers
8209129 security-libs javax.crypto Further improvements to cipher buffer management
8207775 security-libs javax.crypto Better management of CipherCore buffers

Changes in Java SE 8u181 b33

Bug Fixes

BugId Category Subcategory Description
8202696 client-libs javax.swing Remove exclusion range for phonetic chars in windows fontconfig.properties
8206242
(Confidential)
deploy webstart Java Web Start checks "user.dir" read permission when opening http connection

Changes in Java SE 8u181 b32

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

Bug Fixes

BugId Category Subcategory Description
8195095 client-libs javax.swing Images are not scaled correctly in JEditorPane

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_181-b13
7 1.7.0_191-b08
6 1.6.0_201-b07

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

BugId Category Subcategory Description
8189161 (Confidential) deploy deployment_toolkit JWS: Method required to clean up all running instances by jnlp.sis.sessionid
8189098 (Confidential) deploy webstart JWS: Request for a method to limit the number of JVMs running on the client

Changes in Java SE 8u172 b35

Bug Fixes

BugId Category Subcategory Description
8200359 core-libs java.time (tz) Upgrade time-zone data to tzdata2018d
8196491 xml jax-ws Newlines in JAXB string values of SOAP-requests are escaped to " "
8164480 hotspot compiler Crash with assert(handler_address == SharedRuntime::compute_compiled_exc_handler(..) failed: Must be the same
8194690 deploy webstart JRE bundled in App-V package will not start Java Web Start applications
8199304 deploy webstart javaws.exe failed to launch UTF-8 encoded JNLP file
8196011 javafx web Intermittent crash when using WebView from JFXPanel applications

Changes in Java SE 8u172 b31

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

Bug Fixes

BugId Category Subcategory Description
8198794 hotspot runtime Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
8197518 security-libs org.ietf.jgss Kerberos krb5 authentication: AuthList's put method leads to performance issue
8199406 hotspot gc Performance drop with Java JDK 1.8.0_162-b32

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 Family Version JRE Security Baseline
(Full Version String)
8 1.8.0_171-b11
7 1.7.0_181-b09
6 1.6.0_191-b09

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 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

docs/release_notes

Description for Toolkit.getImage() and Toolkit.createImage()

The changes made under JDK-8033530 introduced an inconsistency between the implementation for and the documentation of the following methods:

  • java.awt.Toolkit.getImage(URL u)
  • java.awt.Toolkit.createimage(URL u)

The description in the API document should read:

This method first checks if there is a security manager installed. If so, the method calls the security managers checkPermission() method with the corresponding permission to ensure that the access to the image or the image creation is allowed. If the connection to the specified URL requires either URLPermission or SocketPermission, then URLPermission is used for security checks.

JDK-8154405

Changes

client-libs/java.awt

Touch Keyboard for Swing/AWT Text Components

This release adds support for automatically showing the touch keyboard for Swing/AWT text components on Microsoft Windows 8 or later. A user can display the touch keyboard either by using a touch screen to tap the text component area or by using a mouse to click in the area, when a keyboard is not attached to a computer.

The system property awt.touchKeyboardAutoShowIsEnabled controls whether this functionality is enabled in the JDK. This functionality is enabled by default. However, if the functionality is not needed, the user can switch it off from the command line by setting the system property to false:

-Dawt.touchKeyboardAutoShowIsEnabled=false

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_171-b11
7 1.7.0_181-b09
6 1.6.0_191-b09

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 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

 Enhanced KeyStore Mechanisms

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

 Additional TeliaSonera Root Certificate 

"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

BugId Category Subcategory Description
8187635 client-libs java.awt On Windows Swing changes keyboard layout on a window activation
8187803 client-libs javax.swing JDK part of JavaFX-Swing dialogs appearing behind main stage
8185634 javafx swing Java Fx-Swing dialogs appearing behind main stage
8189280 javafx swing Memory leak in SwingNode if Stage is not shown

Changes in Java SE 8u162 b36

Bug Fixes

BugId Category Subcategory Description
8076117 security-libs java.security EndEntityChecker should not process custom extensions after PKIX validation
8176072 client-libs java.awt READING attributes are not available on TSF
8183504 client-libs javax.swing 8u131 Win 10, issue with wrong position of Sogou IME popup

Changes in Java SE 8u162 b35

Bug Fixes

BugId Category Subcategory Description
8171452 core-libs java.nio (ch) linux io_util_md: Operation not supported exception after 8168628
8168628 core-libs java.nio (fc) SIGBUS when extending file size to map it
8187577 hotspot gc JVM crash during gc doing concurrent marking
8196912 deploy plugin Java Plugin - CRL lookup does external search, with internal CRL configured

Changes in Java SE 8u162 b34

Bug Fixes

BugId Category Subcategory Description
8196332
(Confidential)
deploy plugin settings are written to the root drive on Windows-10 with MSI installer
8074373 tools launcher NMT is not enabled if NMT option is specified after class path specifiers
8192987 security-libs java.security keytool should remember real storetype if it is not provided
8187045 infrastructure build [linux] Not all libraries in the VM are linked with -z,noexecstack

Changes in Java SE 8u162 b32

Bug Fixes

BugId Category Subcategory Description
8057570 hotspot jvmti RedefineClasses() tests fail assert(((Metadata*)obj)->is_valid()) failed: obj is valid
8156137 hotspot compiler SIGSEGV in ReceiverTypeData::clean_weak_klass_links
8055008 hotspot jvmti Clean up code that saves the previous versions of redefined classes
8038636 hotspot compiler speculative traps break when classes are redefined

Changes in Java SE 8u162 b31

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

Bug Fixes

BugId Category Subcategory Description
8054213 core-libs java.lang:reflect Class name repeated in output of Type.toString()
8189789 core-libs java.util.jar tomcat gzip-compressed response bodies appear to be broken in update 151

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_161-b12
7 1.7.0_171-b11
6 1.6.0_181-b10

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_161-b12
7 1.7.0_171-b11
6 1.6.0_181-b10

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.

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:

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

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
  3. The overrideDefaultParser property can be set through the System.setProperty.

  4. Support as a JAXP system property
  5. The overrideDefaultParser property can be set in the JAXP configuration file jaxp.properties.

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

BugId Category Subcategory Description
8191608 install install Java RPMs should allow for side-by-side installation of JDK and JRE, 32 and 64 bit, and only one update for each major version
8193218 install install Simplify build system building rpms
8191607 install install undo 8189805: 64 and 32 bit RPMS must co-exist
8189805 install install 64 and 32 bit RPMS must co-exist

Changes in Java SE 8u152 b34

Bug Fixes

BugId Category Subcategory Description
8179665 client-libs javax.swing [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
8186441 xml jax-ws Change of behavior in the getMessage () method of the SOAPMessageContextImpl class
8185661 deploy webstart JNLP files won't launch from IE11 on Windows 10 Creators Update
8189612
(Confidential)
deploy webstart com.sun.deploy.net.JARSigningException: Found unsigned entry in resource
8173129
(Confidential)
deploy plugin [deploy] System must be left clean after the uninstall process completes
8193168
(Confidential)
deploy javafx Failed to launch the FX application after clicking link 'click to launch this app as webstart'

Changes in Java SE 8u152 b33

Bug Fixes

BugId Category Subcategory Description
8184271 hotspot compiler Time related C1 intrinsics produce inconsistent results when floating around
8190258 core-libs java.time (tz) Support tzdata2017c
8190259 core-libs java.time test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c

Changes in Java SE 8u152 b32

Bug Fixes

BugId Category Subcategory Description
6988950 core-svc debugger JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)
8134103
(Confidential)
core-svc debugger JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface
8182402
(Confidential)
client-libs swing Tooltip for Desktop button is in English when non-English locale is set

Changes in Java SE 8u152 b31

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

Bug Fixes

BugId Category Subcategory Description
8184328 core-libs java.net JDK 8u131 socketRead0 hang at SSL read
8185346 core-libs java.rmi Relax RMI Registry Serial Filter to allow arrays of any type
8185864
(Confidential)
install install JDK 8 Install wizard is hidden after JRE silent install is used
8160365 deploy webstart Desktop shortcut of Web Start application is broken after JRE update

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_151-b12
7 1.7.0_161-b13
6 1.6.0_171-b13

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_151-b12
7 1.7.0_161-b13
6 1.6.0_171-b13

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

security-libs/java.security

Better keystore handling

Due to the more rigorous procedure of reading a keystore content, some keystores (particularly, those created with old versions of the JDK or with a JDK from other vendors) might need to be regenerated.

The following procedure can be used to import the keystore:

1. Before you start, create a backup of your keystore. For example, if your keystore file is /DIR/KEYSTORE, make a copy of it:

cp /DIR/KEYSTORE /DIR/KEYSTORE.BK

Download an older release of the JDK, prior CPU17_04, and install it in a separate location. For example: 6u161, 7u151, or 8u141. Suppose, that older JDK is installed in the directory /JDK8U141

2. Make sure that the keystore can be successfully read with the keytool from that older directory. For example, if the keystore file is located in /DIR/KEYSTORE, the following command should successfully list its content:

/JDK8U141/bin/keytool -list /DIR/KEYSTORE

3. Import the keystore. For example:


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

        

4. Verify that the newly created keystore is correct. At the very least, make sure that the keystore can be read with keytool from a newer JDK:

/NEW_JDK/bin/keytool -list /DIR/KEYSTORE.NEW

After successful verification, replace the old keystore with the new one:

mv /DIR/KEYSTORE.NEW /DIR/KEYSTORE

Keep the backup copy of the keystore at least until you are sure the imported keystore is correct.

JDK-8181370 (not public)

core-libs/java.net

Default timeouts have changed for FTP URL handler

Timeouts used by the FTP URL protocol handler have been changed from infinite to 5 minutes. This will result in an IOException from connect and read operations if the FTP server is unresponsive. For example, new URL("ftp://example.com").openStream().read(), will fail with java.net.SocketTimeoutException in case a connection or reading could not be completed within 5 minutes.

To revert this behaviour to that of previous releases, the following system properties may be used, sun.net.client.defaultReadTimeout=0, sun.net.client.defaultConnectTimeout=0

JDK-8181612 (not public)

install

Demo references in Solaris install documentation

Demos were removed from package tar.Z bundle(JDK-7066713). There is a separate Demos&Samples bundle beginning with 7u2 b08 and 6u32 b04, but Solaris patches still contain SUNWj7dmo/SUNWj6dmo. The 64 bit packages are SUNWj7dmx/SUNWj6dmx

Demo packages remain in the existing Solaris patches; however, just because they are there doesn't mean that they are installed. They will be patched only if the end user has them installed on the system.

http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html

The link above is to the Solaris OS Install Directions for the JDK. The SUNWj7dmx package is mentioned in the tar.Z portion of the directions. This is confusing to some as, according to the cited bug, the SUNWj7dmx package shouldn't be part of the tar.Z bundle.

See JDK-8175866

Certificate Changes

Remove revoked Swisscom root certificate "swisscomrootevca2"

One Swisscom root certificate has been revoked by Swisscom and has been removed:


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

JDK-8186330 (not public)

New Features

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 by using the Security.setProperty() call before the JCE framework has been initialized, that setting will be honored. By default, the property will be undefined. If the property is undefined and the legacy JCE jurisdiction files don't exist in the legacy lib/security directory, then the default cryptographic level will remain at 'limited'. To configure the JDK to use unlimited cryptography, set the crypto.policy to a value of 'unlimited'. See the notes in the java.security file shipping with this release for more information.

Note: On Solaris, it's recommended that you remove the old SVR4 packages before installing the new JDK updates. If an SVR4 based upgrade (without uninstalling the old packages) is being done on a JDK release earlier than 6u131, 7u121, 8u111, then you should set the new crypto.policy Security property in the java.security file.

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

Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)

See JDK-8157561

Changes

security-libs/java.security

Refactor existing providers to refer to the same constants for default values for key length

Two important changes have been made for this issue:

1. A new system property has been introduced that allows users to configure the default key size used by the JDK provider implementations of KeyPairGenerator and AlgorithmParameterGenerator. This property is named "jdk.security.defaultKeySize" and the value of this property is a list of comma-separated entries. Each entry consists of a case-insensitive algorithm name and the corresponding default key size (in decimal) separated by ":". In addition, white space is ignored.

By default, this property will not have a value, and JDK providers will use their own default values. Entries containing an unrecognized algorithm name will be ignored. If the specified default key size is not a parseable decimal integer, that entry will be ignored as well.

2. The DSA KeyPairGenerator implementation of the SUN provider no longer implements java.security.interfaces.DSAKeyPairGenerator. Applications which cast the SUN provider's DSA KeyPairGenerator object to a java.security.interfaces.DSAKeyPairGenerator can set the system property "jdk.security.legacyDSAKeyPairGenerator". If the value of this property is "true", the SUN provider will return a DSA KeyPairGenerator object which implements the java.security.interfaces.DSAKeyPairGenerator interface. This legacy implementation will use the same default value as specified by the javadoc in the interface.

By default, this property will not have a value, and the SUN provider will return a DSA KeyPairGenerator object which does not implement the forementioned interface and thus can determine its own provider-specific default value as stated in the java.security.KeyPairGenerator class or by the "jdk.security.defaultKeySize" system property if set.

JDK-8181048 (not public)

core-libs/java.util:collections

Collections use serialization filter to limit array sizes

Deserialization of certain collection instances will cause arrays to be allocated. The ObjectInputFilter.checkInput() method is now called prior to allocation of these arrays. Deserializing instances of ArrayDeque, ArrayList, IdentityHashMap, PriorityQueue, java.util.concurrent.CopyOnWriteArrayList, and the immutable collections (as returned by List.of, Set.of, and Map.of) will call checkInput() with a FilterInfo instance whose style="font-family: Courier New;">serialClass() method returns Object[].class. Deserializing instances of HashMap, HashSet, Hashtable, and Properties will call checkInput() with a FilterInfo instance whose serialClass() method returns Map.Entry[].class. In both cases, the FilterInfo.arrayLength() method will return the actual length of the array to be allocated. The exact circumstances under which the serialization filter is called, and with what information, is subject to change in future releases.

JDK-8174109 (not public)

security-libs/java.security

keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms

With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing TrustedCertificateEntry, either in the keystore directly operated on or in the cacerts keystore when the -trustcacerts option is specified for the -importcert command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file cert contains a CA certificate signed with a weak signature algorithm, keytool -printcert -file cert and keytool -importcert -file cert -alias ca -keystore ks will print out a warning, but after the last command imports it into the keystore, keytool -list -alias ca -keystore ks will not show a warning anymore.

Precisely, an algorithm or a key is weak if it matches the value of the jdk.certpath.disabledAlgorithms security property defined in the conf/security/java.security file.

See JDK-8171319

security-libs/java.security

New defaults for DSA keys in jarsigner and keytool

For DSA keys, the default signature algorithm for keytool and jarsigner has changed from SHA1withDSA to SHA256withDSA and the default key size for keytool has changed from 1024 bits to 2048 bits.

Users wishing to revert to the previous behavior can use the -sigalg option of keytool and jarsigner and specify SHA1withDSA and the -keysize option of keytool and specify 1024.

There are a few potential compatibility risks associated with this change:

  1. If you have a script that uses the default key size of keytool to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:
    
                    keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
    keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...
                    

    it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:

    
                    keytool error: java.security.InvalidKeyException: The security strength of 
    SHA-1 digest algorithm is not sufficient for this key size
    keytool error: java.security.InvalidKeyException: DSA key must be at most 
    1024 bits
                    

    The workaround is to remove the -sigalg option and use the stronger SHA256withDSA default or, at your own risk, use the -keysize option of keytool to specify a smaller key size (1024).

  2. If you use jarsigner to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. jarsigner -verify on an earlier release of JDK 6 or 7 will output the following error:

    jar is unsigned. (signatures missing or not parsable)

    If you add -J-Djava.security.debug=jar to the jarsigner command line, the cause will be output:

    
                    jar: processEntry caught: java.security.NoSuchAlgorithmException: 
    SHA256withDSA Signature not available
                    

    If compatibility with earlier releases is important, you can, at your own risk, use the -sigalg option of jarsigner and specify the weaker SHA1withDSA algorithm.

  3. If you use a PKCS11 keystore, the SunPKCS11 provider does not support the SHA256withDSA algorithm. jarsigner and some keytool commands may fail with the following exception if PKCS11 is specified with the -storetype option, ex:
    
                    keytool error: java.security.InvalidKeyException: No installed provider
    supports this key: sun.security.pkcs11.P11Key$P11PrivateKey 
                    

    A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the -sigalg option of keytool and specify SHA1withDSA.

See JDK-8057810

security-libs/java.security

Add warnings to keytool when using JKS and JCEKS

When keytool is operating on a JKS or JCEKS keystore, a warning may be shown that the keystore uses a proprietary format and migrating to PKCS12 is recommended. The keytool's -importkeystore command is also updated so that it can convert a keystore from one type to another if the source and destination point to the same file.

JDK-8182879 (not public)

security-libs/java.security

keytool now prints out information of a certificate's public key

Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: <size>-bit RSA key", where <size> is the key size in bits (ex: 2048).

See JDK-8029659

tools

Improve javadoc generation

The Javadoc Standard Doclet documentation has been enhanced to specify that it doesn't validate the content of documentation comments for conformance, nor does it attempt to correct any errors in documentation comments. See the Conformance section in the Doclet documentation.

JDK-8179042 (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 8u151 Bug Fixes page.

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

BugId Category Subcategory Description
8159035
(Confidential)
security-libs javax.crypto com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0

Changes in Java SE 8u144 b33

Bug Fixes

BugId Category Subcategory Description
8185572 hotspot compiler Enable AssumeMP by default on SPARC machines
8074544 deploy webstart webstart app fails with CouldNotLoadArgumentException when account in Japanese
8133531
(Confidential)
deploy webstart deployJava.launchWebStartApplication() couldn't work
8129820
(Confidential)
deploy webstart Crash in native javaws base64 code
8180490
(Confidential)
deploy plugin Forms context lost when legacy_lifecycle=yes

Changes in Java SE 8u144 b32

Bug Fixes

BugId Category Subcategory Description
8180048 hotspot gc Interned string and symbol table leak memory during parallel unlinking
8175169
(Confidential)
deploy webstart Reduce security dialogs when only application args change
8180457
(Confidential)
deploy webstart WebStart cached jar verification intermittently slow in native ReadFile function

Changes in Java SE 8u144 b31

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

Bug Fixes

BugId Category Subcategory Description
8134389 hotspot compiler Crash in HotSpot with jvm.dll+0x42b48 ciObjectFactory::create_new_metadata
8158639 hotspot compiler C2 compilation fails with SIGSEGV

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_141-b15
7 1.7.0_151-b15
6 1.6.0_161-b13

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

core-libs/java.util.jar

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) ).
  5. NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.

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

BugId Category Subcategory Description
8164410 deploy plugin JRE 6u121 causes applet to fail with: Reset deny session certificate store
8178536 hotspot svc OOM ERRORS + SERVICE-THREAD TAKES A PROCESSOR TO 100%
8161598
(Confidential)
hotspot compiler Kitchensink fails: assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod/CompiledMethod
8182672
(Confidential)
core-libs java.net Java 8u121 on Linux intermittently returns null for MAC address

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_141-b15
7 1.7.0_151-b15
6 1.6.0_161-b13

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) ).
  5. NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.

  6. Re-sign the JAR file.
  7. [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

BugId Category Subcategory Description
8173654 core-libs java.lang Regression since 8u60: System.getenv doesn't return env var set in JNI code
8075484 core-libs java.net SocketInputStream.socketRead0 can hang even with soTimeout set
8180660 tools javac missing LNT entry for finally block
8164119 client-libs java.awt MoveToOtherScreenTest fails due wrong key attribute
8181192 client-libs 2d [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS
8172297 xml jax-ws In java 8, the marshalling with JAX-WS does not escape carriage return
8181057
(Confidential)
deploy webstart [regression] Fix of JDK-8174177 breaks existing scenarios of SingleInstanceService.
8181892
(Confidential)
core-svc tools Fix usagetracker use of getEnvVar

Changes in Java SE 8u131 b33

Bug Fixes

BugId Category Subcategory Description
8175251 security-libs java.security Failed to load RSA private key from pkcs12
8160696 client-libs java.awt IllegalArgumentException: adding a component to a container on a different GraphicsDevice
8168914 hotspot gc Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking
8174177
(Confidential)
deploy webstart JWS: SAXParseException due to JNLP file not escaped

Changes in Java SE 8u131 b32

Bug Fixes

BugId Category Subcategory Description
8145207 client-libs javax.accessibility [macosx] JList, VO can't access non-visible list items
8076554 client-libs javax.accessibility [macosx] Custom Swing text components need to allow standard accessibility
8165829 client-libs javax.accessibility Android Studio 2.x crashes with NPE at sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
8076249 client-libs javax.accessibility NPE in AccessBridge while editing JList model
8164002 hotspot compiler Add a new CPU family (S_family) for SPARC S7 and above processors
8167102 client-libs 2d [macosx] PrintRequestAttributeSet breaks page size set using PageFormat
8061258 client-libs 2d [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges
8176490
(Confidential)
client-libs java.awt [macosx] Sometimes NSWindow.isZoomed hangs
8177449 core-libs java.time (tz) Support tzdata2017b

Changes in Java SE 8u131 b31

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

Bug Fixes

BugId Category Subcategory Description
8164293 hotspot compiler HotSpot leaking memory in long-running requests
8043913 hotspot compiler remove legacy code in SPARC's VM_Version::platform_features
8049717 hotspot runtime expose L1_data_cache_line_size for diagnostic/sanity checks
8177817 hotspot runtime Remove assertions in 8u that were removed by 8056124 in 9.
8134119 hotspot compiler Use new API to get cache line sizes
8165482 hotspot compiler java in ldoms, with cpu-arch=generic has problems
8165342 javafx scenegraph NPE when JavaFX loads default stylesheet or font families if CCL is null

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_131-b11
7 1.7.0_141-b11
6 1.6.0_151-b10

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

BugId Category Subcategory Description
8058316 client-libs 2d lookupDefaultPrintService returns null on Solaris 11 when default printer is set using lpoptions command
8176044 core-libs java.time (tz) Support tzdata2017a
8165978
(Confidential)
core-libs java.net SocketTest.java fails with NullPointerException
8145826
(Confidential)
core-svc javax.management closed/jdk/management/resource tests fail after JDK-8056152

Changes in Java SE 8u121 b35

Bug Fixes

BugId Category Subcategory Description
8162795 hotspot jvmti [REDO] MemberNameTable doesn't purge stale entries
8171808 client-libs javax.accessibility Performance problems in dialogs with large tables when JAB activated
8170950 client-libs 2d Text is displayed in bold when fonts are installed into symlinked folder
8163979 client-libs java.awt [macosx] Chinese text shows as Latin w/ openVanilla input method
8163889
(Confidential)
client-libs java.awt [macosx] Can't print from browser on Mac OS X
8171388
(Confidential)
core-libs javax.naming Update JNDI Thread contexts

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

BugId Category Subcategory Description
8173783 security-libs javax.net.ssl IllegalArgumentException: jdk.tls.namedGroups
8173145 client-libs javax.swing Menu is activated after using mnemonic Alt/Key combination
8038348 hotspot compiler Instance field load is replaced by wrong data Phi
8170888 hotspot runtime [linux] Experimental support for cgroup memory limits in container (ie Docker) environments
6515172 hotspot runtime Runtime.availableProcessors() ignores Linux taskset command
8147910 hotspot runtime Cache initial active_processor_count
8165153 hotspot runtime Crash in rebuild_cpu_to_node_map
8161993 hotspot gc G1 crashes if active_processor_count changes during startup
8170307
(Confidential)
hotspot runtime Stack size option -Xss is ignored
8157184
(Confidential)
hotspot compiler java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed with a fatal error
8166158
(Confidential)
deploy webstart correct version of jar is not asked in some cases when jar is originally downloaded using loadResource

Changes in Java SE 8u121 b33

Bug Fixes

BugId Category Subcategory Description
8169465 core-libs javax.naming Deadlock in com.sun.jndi.ldap.pool.Connections
8152981 client-libs javax.swing Double icons with JMenuItem setHorizontalTextPosition on Win 10
8075516 client-libs java.awt Deleting a file from either the open or save java.awt.FileDialog hangs.
7172652 client-libs javax.swing With JDK 1.7 text field does not obtain focus when using mnemonic Alt/Key combin
8159058 xml jax-ws SAXParseException when sending soap message
8141054 deploy webstart WebStart does not clean up jnlp file after closing
8169541
(Confidential)
deploy deployment_toolkit security pop-up triggers each time when launching application
8170668
(Confidential)
deploy webstart java.lang.UnsupportedOperationException in javaws applications
8168070
(Confidential)
deploy webstart Extra window appears due to Preloader failed to handle AppletInitEvent

Changes in Java SE 8u121 b31

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

Bug Fixes

BugId Category Subcategory Description
8167179 xml jaxp Make XSL generated namespace prefixes local to transformation process
8166208 hotspot svc FlightRecorderOptions settings for defaultrecording ignored.
8155211 security-libs java.security Ucrypto Library leaks native memory
8035568 client-libs java.awt [macosx] Cursor management unification
8169589 client-libs java.awt [macosx] Activating a JDialog puts to back another dialog
8163195
(Confidential)
deploy webstart Release DeploymentRuleSet.jar as soon as app is launched
8160275
(Confidential)
deploy deployment_toolkit 7u95 java does not start after the java splash screen in jws application
8161609
(Confidential)
deploy plugin Deploy starts applets even if mandatory config hasn't been found
8164476
(Confidential)
deploy deployment_toolkit JWS: JNLP file not removed when using SingleInstanceService
8171949
(Confidential)
client-libs java.awt [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state
8171952
(Confidential)
client-libs java.awt [macosx] ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked.

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_121-b13
7 1.7.0_131-b12
6 1.6.0_141-b12

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

BugId Category Subcategory Description
8157548 hotspot runtime JVM crashes sometimes while starting
8169191 core-libs java.time (tz) Support tzdata2016i

Changes in Java SE 8u112 b31

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

Bug Fixes

BugId Category Subcategory Description
8166591 client-libs javax.swing [macos 10.12] Trackpad scrolling of text on macOS 10.12 Sierra is very fast (Trackpad, Retina only)
8166875 core-libs java.time (tz) Support tzdata2016g
8063089
(Confidential)
hotspot jfr VM fails to start on Windows with enabled JFR

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_111-b14
7 1.7.0_121-b15
6 1.6.0_131-b14

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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_111-b14
7 1.7.0_121-b15
6 1.6.0_131-b14

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

BugId Category Subcategory Description
8152438 hotspot gc Threads may do significant work out of the non-shared overflow buffer
8159410 core-libs java.net InetAddress.isReachable returns true for non existing IP addresses

Changes in Java SE 8u102 b34

Bug Fixes

BugId Category Subcategory Description
8153438 security-libs javax.smartcardio Avoid repeated "Please insert a smart card" popup windows
8164942
(Confidential)
deploy webstart Avoid repeated "Please insert a smart card" popup windows - DEPLOY part

Changes in Java SE 8u102 b33

Bug Fixes

BugId Category Subcategory Description
8141148 core-libs javax.naming LDAP "follow" throws ClassCastException with Java 8
8148984 client-libs java.awt [macosx] Chinese Comma cannot be entered using Pinyin Input Method on OS X
8158111 security-libs javax.net.ssl Make handling of 3rd party providers more stable
8080729 client-libs java.awt [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus
8163583 client-libs java.awt [macosx] Press "To Back" button on the Dialog,the Dialog moves behind the Frame

Changes in Java SE 8u102 b31

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

Bug Fixes

BugId Category Subcategory Description
8154788
(Confidential)
install install ENT MSI installers should support system account

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 Family Version JRE Security Baseline(Full Version String)
8 1.8.0_101-b13
7 1.7.0_111-b13
6 1.6.0_121-b09

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 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 Family Version JRE Security Baseline (Full Version String)
8 1.8.0_101-b13
7 1.7.0_111-b13
6 1.6.0_121-b09

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 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/technetwork/java/javase/family-clsid-140615.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

BugId Category Subcategory Description
8132434 install install On Mac Install Run javawslauncher.app to register protocol handler with Launch Services
8159244 hotspot compiler Partially initialized string object created by C2's string concat optimization may escape
8155068
(Confidential)
deploy webstart jnlp protocol is not registered on mac after installing jre
8136844 deploy webstart Change JavawsLauncher.app to use NSTask or execv
8081847 deploy webstart Add a URL scheme handler to reliably launch .jnlp files - Mac registration part
8156977
(Confidential)
deploy webstart java.lang.NumberFormatException: For input string: 1z
8144348 deploy webstart Desktop shortcut is not updated after JNLP is changed in deployment cache

Changes in Java SE 8u92 b33

Bug Fixes

BugId Category Subcategory Description
6882559 client-libs javax.swing new JEditorPane("text/plain","") fails for null context class loader
8154899 deploy webstart System property 'user.dir' now set to 'java.home' value rather than user's working directory
8156822 deploy webstart Application started using javaws now starts in {java.home} rather than current directory
8063086 hotspot compiler Math.pow yields different results upon repeated calls
8158734 client-libs javax.swing JEditorPane.createEditorKitForContentType throws NPE after 6882559
8154287 javafx media Intermittent crash when disposing MediaPlayer
8153534 javafx media Intermittent hang in GSTMedia.gstDispose
8154186 javafx web JVM crash while using JavaFW WebView and colgroup/cols html feature
8153148 javafx web Defer image decoding until WebCore requests ImageFrame
8153501 javafx web Crash in ResourceLoader::releaseResources()
8153151 javafx web Call JavaScriptCore GC whenever JVM GC happens
8151459 javafx web Validation of new behaviour for JS callback memory leak
8152737 javafx web Crash in RuntimeObject::put when object passed to JSObject::setMember is GCed
8089681 javafx web WebView leaks memory when containing object acts as javascript callback handler
8149537 javafx web JavaFX WebView performance regression when inserting html via javascript
8149768 javafx web JavaFX Application Performance Issue
8147851 javafx web jvm crash at javafx com.sun.webkit.WebPage.twkPrePaint
8149737 javafx web JRE crash in com.sun.webkit.network.URLLoader.twkDidFinishLoading
8139114 javafx web WebView crashes on Yahoo login page
8154022 javafx build Upgrade production compilers on Windows to Visual Studio 2013 SP4

Changes in Java SE 8u92 b31

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

Bug Fixes

BugId Category Subcategory Description
6483657 security-libs javax.crypto MSCAPI provider does not create unique alias names
8143913 security-libs java.security MSCAPI keystore should accept Certificate[] in setEntry()
8145844
(Confidential)
deploy plugin JARSigningException when loading jar file from JRE\lib\applet
8152917
(Confidential)
deploy webstart jarUpdate: javaws app has unexpectedly updated after choosing "cancel" on "Application Update" window

Java™ SE Development Kit 8, Update 92 (JDK 8u92)

The full version string for this update release is 1.8.0_92-b14 (where "b" means "build") for the Microsoft Windows JRE and JDK and 1.8.0_92-b14 for all other platforms and for the Microsoft Windows Server JRE. The version number is 8u92.

This update release contains several enhancements and changes including the following. 

IANA Data 2016a

JDK 8u92 contains IANA time zone data version 2016a. 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 8u92 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_91
7 1.7.0_101
6 1.6.0_115

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 8u92) will expire with the release of the next critical patch update scheduled for July 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u92) on August 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.

Bug Fixes

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

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

SHA224 removed from the default support list if SunMSCAPI enabled

SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not yet support SHA224. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time.

To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled.

See JDK-8064330.

New JVM Options added: ExitOnOutOfMemoryError and CrashOnOutOfMemoryError

Two new JVM flags have been added:

  • ExitOnOutOfMemoryError - When you enable this option, the JVM exits on the first occurrence of an out-of-memory error. It can be used if you prefer restarting an instance of the JVM rather than handling out of memory errors.

  • CrashOnOutOfMemoryError - If this option is enabled, when an out-of-memory error occurs, the JVM crashes and produces text and binary crash files (if core files are enabled).

See JDK-8138745.

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

Java™ SE Development Kit 8, Update 91 (JDK 8u91)

The full version string for this update release is 1.8.0_91-b15 (where "b" means "build") for the Microsoft Windows JRE and JDK and 1.8.0_91-b14 for all other platforms and for the Microsoft Windows Server JRE. The version number is 8u91.

This update release contains several enhancements and changes including the following.

IANA Data 2016a

JDK 8u91 contains IANA time zone data version 2016a. 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 8u91 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_91
7 1.7.0_101
6 1.6.0_115

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 8u91) will expire with the release of the next critical patch update scheduled for July 19, 2016.

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

Notes

Removal of Static JREs

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

Bug Fixes

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

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

Regression in Applet startup time fixed

JDK-8080977 introduced delay on applet launch. The delay appears only on IE and lasts about 20 seconds. JDK-8136759 removed this delay.

See JDK-8136759

DSA signature generation is now subject to a key strength check

For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (e.g. using (2048, 256)-bit DSA keys with SHA1withDSA signature), the operation will fail with the error message:

"The security strength of SHA1 digest algorithm is not sufficient for this key size."

JDK-8138593 (not public)

Firefox 42 liveconnect problem

Because it might cause the browser to hang, we don't process JavaScript-to-Java calls when the Java plugin is launched from plugin-container.exe (the default behavior for Firefox 42) and the applet status is not Ready(2). If the applet is not ready (the status is not 2), we don't execute the actual Java method and only return null.

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

Workaround (for Firefox 42):

User’s can set dom.ipc.plugins.enabled=false. The side effect of this workaround is that it changes the setting for all plugins.

JDK-8144079 (not public)

New attribute for JMX RMI JRMP servers specifies a list of class names to use when deserializing server credentials

A new java attribute has been defined for the environment to allow a JMX RMI JRMP server to specify a list of class names. These names correspond to the closure of class names that are expected by the server when deserializing credentials. For instance, if the expected credentials were a List<string>, then the closure would constitute all the concrete classes that should be expected in the serial form of a list of Strings.

By default, this attribute is used only by the default agent with the following:

 {   
   "[Ljava.lang.String;",   
   "java.lang.String" 
 } 

Only arrays of Strings and Strings will be accepted when deserializing the credentials.

The attribute name is:

"jmx.remote.rmi.server.credential.types"

The following is an example of a user starting a server with the specified credentials class names:

Map<String, Object> env = new HashMap<>(1);
 env.put ( 
 "jmx.remote.rmi.server.credential.types",
   new String[]{
   String[].class.getName(),
   String.class.getName()
   }
   );
   JMXConnectorServer server
   = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer);

The new feature should be used by directly specifying:

"jmx.remote.rmi.server.credential.types"

JDK-8144430 (not public)

New certificates added to root CAs

Eight new root certificates have been added :

  1. QuoVadis Root CA 1 G3
  2. alias: quovadisrootca1g3
  3. DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM

  1. QuoVadis Root CA 2 G3
  2. alias: quovadisrootca2g3
  3. DN: CN=QuoVadis Root CA 2 G3

  1. QuoVadis Root CA 3 G3
  2. alias: quovadisrootca3g3
  3. DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM

  1. DigiCert Assured ID Root G2
  2. alias: digicertassuredidg2
  3. DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US

  1. DigiCert Assured ID Root G3
  2. alias: digicertassuredidg3
  3. DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US

  1. DigiCert Global Root G2
  2. alias: digicertglobalrootg2
  3. DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US

  1. DigiCert Global Root G3
  2. alias: digicertglobalrootg3
  3. DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US

  1. DigiCert Trusted Root G4
  2. alias: digicerttrustedrootg4
  3. DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US

See JDK-8145954 and JDK-8145955

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

The following sections summarize changes made in all Java SE 8u77 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 8u77 b31

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

Bug Fixes

BugId Category Subcategory Description
8130150 hotspot compiler Implement BigInteger.montgomeryMultiply intrinsic
8081778 hotspot compiler Use Intel x64 CPU instructions for RSA acceleration
8151522 hotspot compiler Disable 8130150 and 8081778 intrinsics by default
8147994 client.libs javax.swing [macosx] JScrollPane jitters up/down during trackpad scrolling on MacOS/Aqua

Java™ SE Development Kit 8, Update 77 (JDK 8u77)

The full version string for this update release is 1.8.0_77-b03 (where "b" means "build"). The version number is 8u77.

This update release contains several enhancements and changes including the following.

IANA Data 2016a

JDK 8u77 contains IANA time zone data version 2016a. 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 8u77 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_77
7 1.7.0_99
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u77) will expire with the release of the next critical patch update scheduled for April 19, 2016.

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

Notes

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

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

Bug Fixes

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

 

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

The following sections summarize changes made in all Java SE 8u74 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 8u74 b32

Bug Fixes

BugId Category Subcategory Description
6675699 hotspot compiler need comprehensive fix for unconstrained ConvI2L with narrowed typed
8130735 client-libs javax.swing javax.swing.TimerQueue: timer fires late when another timer starts
8038837 security-libs java.security Add support to jarsigner for specifying timestamp hash algorithm
8146336
(Confidential)
deploy plugin pac file returns wrong proxy with IE only due to broken wildcarding
8144864
(Confidential)
deploy plugin .pac file returns wrong proxy
8145712
(Confidential)
deploy webstart NPE is introduced by 8133458

Changes in Java SE 8u74 b31

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

Bug Fixes

BugId Category Subcategory Description
8144963 deploy webstart Javaws checks jar files twice if JVM needs to be restarted
8140291
(Confidential)
deploy webstart (JWS)LazyRootStore leak when calling getResourceAsStream on non-class resource
8142982 deploy webstart Race Condition can cause CacheEntry.getJarSigningData() to return null.

Java™ SE Development Kit 8, Update 74 (JDK 8u74)

The full version string for this update release is 1.8.0_74-b02 (where "b" means "build"). The version number is 8u74.

This update release contains several enhancements and changes including the following. 

IANA Data 2015g

JDK 8u74 contains IANA time zone data version 2015g. 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 8u74 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_71
7 1.7.0_95
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u74) will expire with the release of the next critical patch update scheduled for April 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u74) on May 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

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

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

Bug Fixes

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

Java™ SE Development Kit 8, Update 73 (JDK 8u73)

The full version string for this update release is 1.8.0_73-b02 (where "b" means "build"). The version number is 8u73.

This update release contains several enhancements and changes including the following.

IANA Data 2015g

JDK 8u73 contains IANA time zone data version 2015g. 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 8u73 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_71
7 1.7.0_95
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u73) will expire with the release of the next critical patch update scheduled for April 19, 2016.

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

Notes

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

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

Bug Fixes

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

Note that 8u73 does not contain the PSU builds found in 8u72. Customers who require the additional bug fixes contained in 8u72 should update to 8u74 instead of 8u73.

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

The following sections summarize changes made in all Java SE 8u72 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 8u72 b31

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

Java™ SE Development Kit 8, Update 72 (JDK 8u72)

The full version string for this update release is 1.8.0_72-b15 (where "b" means "build") for the Microsoft Windows JRE and JDK and 1.8.0_72-b15 for all other platforms and for the Microsoft Windows Server JRE. The version number is 8u72.

This update release contains several enhancements and changes including the following. 

IANA Data 2015g

JDK 8u72 contains IANA time zone data version 2015g. 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 8u72 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_71
7 1.7.0_95
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u72) will expire with the release of the next critical patch update scheduled for April 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u72) on May 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.

Bug Fixes

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

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

jps running as root fails after the fix of JDK-8050807
When running jps as root in solaris or linux, it should be able to display process information for all running java process in the system. This worked fine until 7u72:
For example:


jps running In 7u72 solaris machine:
7u72/bin/jps
1771 ControlPanel
722 Bootstrap
1224 ContainerPrivate
1637 swupna.jar
1772 Jp

jps running In 7u75 solaris machine:
7u75/bin/jps 
1746 Jps 
1739 -- process information unavailable 
722 -- process information unavailable 
1224 ContainerPrivate 
1637 -- process information unavailable 

This bug was introduced when fix JDK-8050807 was merged in JDK repository. In this fix UID of directory is matched with the effective Id of process. When JPS command is executed as root, it tries to read the process information from "/tmp/hsperfdata_$username_$ProcessID" file. Before reading the process file or directory, it checks if the file or directory is secure or not. It opens the user directory and match the UID of that directory (which belong to other user) with the current process(root-jps) effective ID,which gets fail and process returns failure.

See JDK-8075773.

"Apply" button is permanently disabled in JCP, after roaming profile option is changed
After the option "Store user settings in the roaming profile" located in "Java Control Panel -> Advanced -> Miscellaneous" is changed and applied by a click on "Apply" button in Java Control Panel (JCP), "Apply" button becomes permanently disabled and changes of any other options in JCP do not lead to enabling of "Apply" button.

See JDK-8133985.

JFR reports abnormally high machine CPU consumption on Linux
On Linux kernels 2.6 and later, the JDK would include time spent waiting for IO completion as "CPU usage". During periods of heavy IO activity, this could result in misleadingly high values reported as CPU consumption in various tools like Flight Recorder and performance counters. This issue has been resolved.

JDK-8133527 (not public)

Problem with REMOVEOUTOFDATEJRES Installer option documentation corrected
Missing documentation for the REMOVEOUTOFDATEJRES installer option was added to the Java Platform, Standard Edition Installation Guide: http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#table_config_file_options

See JDK-8133527.

Java™ SE Development Kit 8, Update 71 (JDK 8u71)

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

This update release contains several enhancements and changes including the following.

IANA Data 2015g

JDK 8u71 contains IANA time zone data version 2015g. 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 8u71 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_71
7 1.7.0_95
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u71) will expire with the release of the next critical patch update scheduled for April 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u71) on May 19, 2016. After either condition is met (new release becoming available or expiration date reached), 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 and Changes

The following are some of the notable new features and changes in this release:

*MD5 now disabled for X509 Certificate validating*
MD5 must not be used for digital signatures where collision resistance is required. To prevent the use of X.509 certificates that include an MD5-based digital signature algorithm, MD5 has been added to the jdk.certpath.disabledAlgorithms security property. Applications should upgrade or replace certificates that include an MD5-based digital signature.

Reversing this change is possible by removing MD5 from the jdk.certpath.disabledAlgorithms security property in the java.security file. This is not recommended.
JDK-8141287 (not public)

Disable MD5withRSA signature algorithm in the JSSE provider
The MD5withRSA signature algorithm is now considered insecure and should no longer be used. Accordingly, MD5withRSA has been deactivated by default in the Oracle JSSE implementation by adding "MD5withRSA" to the "jdk.tls.disabledAlgorithms" security property. Now, both TLS handshake messages and X.509 certificates signed with MD5withRSA algorithm are no longer acceptable by default. This change extends the previous MD5-based certificate restriction ("jdk.certpath.disabledAlgorithms") to also include handshake messages in TLS version 1.2. If required, this algorithm can be reactivated by removing "MD5withRSA" from the "jdk.tls.disabledAlgorithms" security property.
JDK-8144773 (not public)

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see JDK 8u71 Bug Fixes page. The following are some of the notable bug fixes included in this release:

Running jps as root does not show all information
After the fix of JDK-8050807 (fixed in 8u31, 7u75 and 6u91), running jps as root did not show all the information from Java processes started by other users on some systems. This has now been fixed.
See JDK-8075773.

Installers appearing stalled on ESC configurations
Users running Internet Explorer Enhance Security Configuration (ESC) on Windows Server 2008 R2 may have experienced issues installing Java in interactive mode. This issue has been resolved in the 8u71 release. Installers executed in interactive mode will no longer appear to be stalled on ESC configurations.
See JDK-8140197.

Problem with PBE algorithms using AES crypto corrected
An error was corrected for PBE using 256-bit AES ciphers such that the derived key may be different and not equivalent to keys previously derived from the same password.
JDK-8138589 (not public)
 

Problem with Enterprise MSI switch 'REMOVEOLDERJRES' documentation corrected
The Enterprise MSI documentation lists configuration options:

The REMOVEOLDERJRES option used to uninstall old JREs was missing. Added this option, with the description:
If set to 1, removes older releases of the JRE installed on the system.
Default: 0 does not remove any old JREs
JDK-8081237 (not public)

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

The following sections summarize changes made in all Java SE 8u66 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 8u66 b36

Bug Fixes

BugId Category Subcategory Description
8130212
(Confidential)
hotspot runtime Thread::current() might access freed memory on Solaris
8132890 client-libs 2d Text Overlapping on Dot Matrix Printers
8133458
(Confidential)
deploy webstart 8u51 is slower than 6u101 to launch JWS application
8098826
(Confidential)
deploy webstart WS sends multiple request to server to download extensions
8141527 deploy webstart AddRemoveTest tests fail as second request to jnlp not getting to server, but resource requests going through fine

Changes in Java SE 8u66 b35

Bug Fixes

BugId Category Subcategory Description
8142908
(Confidential)
deploy plugin Java Plug-in crashes under some scenarios using FF42
8133523 deploy plugin _releaseObject called from wrong thread
8134828 client-libs javax.swing Scrollbar thumb disappears with Nimbus L&F
8144110
(Confidential)
install install 32-bit JRE install fails on 64-bit Windows Server 2012 under System Account
8140670
(Confidential)
install install 32-bit JRE silent install fails on 64-bit Windows under System Account
8067422 tools javac Lambda method names are unnecessarily unstable

Changes in Java SE 8u66 b33

Bug Fixes

BugId Category Subcategory Description
8136759
(Confidential)
deploy deployment_toolkit Regression in Applet startup time with Internet Explorer on 8u60 and 8u65-b14

Changes in Java SE 8u66 b31

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

Bug Fixes

BugId Category Subcategory Description
8135307
(Confidential)
tools javac CompletionFailure thrown when calling FieldDoc.type, if the field's type is missing

Java™ SE Development Kit 8, Update 66 (JDK 8u66)

The full version string for this update release is 1.8.0_66-b18 (where "b" means "build") for the Microsoft Windows JRE and JDK and 1.8.0_66-b17 for all other platforms and for the Microsoft Windows Server JRE. The version number is 8u66.

This update release contains several enhancements and changes including the following. 

IANA Data 2015f

JDK 8u66 contains IANA time zone data version 2015f. 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 8u66 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_65
7 1.7.0_91
6 1.6.0_105

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u66) will expire with the release of the next critical patch update scheduled for January 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u66) on February 20, 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

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

New Features and Changes

The following are some of the notable new features and changes in this release:
 

Support ISO 4217 "Current funds codes" table (A.2)

This enhancement adds support for ISO 4217 table A.2 fund codes. Previously the JDK only supported those currencies listed in table A.1.
See JDK-8074350.


Bug Fixes

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

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

Kerberos changes for applications running with security manager
This JDK release introduces some changes to how Kerberos requests are handled when a security manager is present.

Note that if a security manager is installed while a KerberosPricipal is being created, a {@link ServicePermission} must be granted and the service principal of the permission must minimally be inside the {@code KerberosPrincipal}'s realm.

For example, if the result of {@code new KerberosPrincipal("user")} is {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted.

Also note that if a single GSS-API principal entity that contains a Kerberos name element without providing its realm is being created via the org.ietf.jgss.GSSName interface and a security manager is installed, then this release introduces a new requirement. A {@link javax.security.auth.kerberos.ServicePermission ServicePermission} must be granted and the service principal of the permission must minimally be inside the Kerberos name element's realm.

For example, if the result of {@link GSSManager#createName(String, Oid) createName("user", NT_USER_NAME)} contains a Kerberos name element {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted. Otherwise, the creation will throw a {@link GSSException} containing the {@code GSSException.FAILURE} error code.
JDK-8048030 (not public)

Hotspot should use PICL interface to get cacheline size on SPARC
The libpicl library is now required on Solaris/SPARC to determine the size of the cache lines. In case the library is not present or the PICL service is not available the JVM will display a warning and compiler optimizations that utilize the BIS (Block Initializing Store) instruction will be turned off.
See JDK-8056124.

Preloading libjsig.dylib causes deadlock when signal() is called
Applications need to preload the libjsig library to enable signal chaining. Previously, on OS X, after libjsig.dylib was preloaded, any call from native code to signal() caused a deadlock. This has been corrected.
See JDK-8072147.

VM crash when class is redefined with Instrumentation.redefineClasses
The JVM could crash when a class was redefined with Instrumentation.redefineClasses(). The crash could either be a segmentation fault at SystemDictionary::resolve_or_null, or an internal error with the message "tag mismatch with resolution error table". This has now been fixed.
See JDK-8076110.

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

Java plug-in does not work in Firefox after installing Java
Firefox 42 may crash when trying to run the Java plug-in.

NOTE: The workaround applies to Firefox 42 and requires Windows Java Version 8 Update 66 Build 18 or later versions.

See JDK-8133523 for related information.

There are several workaround options. The simplest method is noted first and is recommended. The remaining available options are not recommended for non-technical users.

Option 1: Add property name dom.ipc.plugins.java.enabled in Firefox preferences

  1. Launch Firefox
  2. Type about:config in the address bar
  3. You will be presented with a Firefox warning about the configuration settings. After acknowledging the Firefox alert, you should see a listing of the configuration preferences.
  4. Right-click anywhere inside the displayed list of preferences. Select New then select Boolean.
  5. Add property name as dom.ipc.plugins.java.enabled
  6. Add Preference name as dom.ipc.plugins.java.enabled.
  7. A window will be displayed, select false. Then select OK.

Option 2: Create "user.js" file with preference entry

Instructions are based on Mozilla references listed below.

  1. Use a text editor to create a "user.js" file in your Firefox profiles folder
  2. Add entry: user_pref("dom.ipc.plugins.java.enabled", false);

Option 3: Update "pref.js" file with preference entry  

  1. Locate the "pref.js" file in the Mozilla profiles folder
  2. Find and update preference: user_pref("dom.ipc.plugins.java.enabled", false);

Correction to end time checking for native TGT
The end times for native TGTs (ticket-granting tickets) are now compared with UTC time stamps.
See JDK-8078495.

Java™ SE Development Kit 8, Update 65 (JDK 8u65)

The full version string for this update release is 1.8.0_65-b17 (where "b" means "build"). The version number is 8u65.

This update release contains several enhancements and changes including the following.

IANA Data 2015f

JDK 8u65 contains IANA time zone data version 2015f. 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 8u65 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_65
7 1.7.0_91
6 1.6.0_105

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u65) will expire with the release of the next critical patch update scheduled for January 19, 2016.

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

Notes

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

New Features and Changes

The following are some of the notable new features and changes in this release:

Support ISO 4217 "Current funds codes" table (A.2)

This enhancement adds support for ISO 4217 table A.2 fund codes. Previously the JDK only supported those currencies listed in table A.1.

See JDK-8074350.

Bug Fixes

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

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

Kerberos changes for applications running with security manager

This JDK release introduces some changes to how Kerberos requests are handled when a security manager is present.

Note that if a security manager is installed while a KerberosPricipal is being created, a {@link ServicePermission} must be granted and the service principal of the permission must minimally be inside the {@code KerberosPrincipal}'s realm.

For example, if the result of {@code new KerberosPrincipal("user")} is {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted.

Also note that if a single GSS-API principal entity that contains a Kerberos name element without providing its realm is being created via the org.ietf.jgss.GSSName interface and a security manager is installed, then this release introduces a new requirement. A {@link javax.security.auth.kerberos.ServicePermission ServicePermission} must be granted and the service principal of the permission must minimally be inside the Kerberos name element's realm.

For example, if the result of {@link GSSManager#createName(String, Oid) createName("user", NT_USER_NAME)} contains a Kerberos name element {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted. Otherwise, the creation will throw a {@link GSSException} containing the {@code GSSException.FAILURE} error code.

JDK-8048030 (not public)

Hotspot should use PICL interface to get cacheline size on SPARC

The libpicl library is now required on Solaris/SPARC to determine the size of the cache lines. In case the library is not present or the PICL service is not available the JVM will display a warning and compiler optimizations that utilize the BIS (Block Initializing Store) instruction will be turned off.

See JDK-8056124.

Preloading libjsig.dylib causes deadlock when signal() is called

Applications need to preload the libjsig library to enable signal chaining. Previously, on OS X, after libjsig.dylib was preloaded, any call from native code to signal() caused a deadlock. This has been corrected.

See JDK-8072147.

Use Safe Prime Diffie-Hellman Groups

In the JDK SSL/TLS implementation (SunJSSE provider), safe prime Diffie-Hellman groups are used by default. Users can customize Diffie-Hellman groups with the security property, "jdk.tls.server.defaultDHEParameters".

[macosx] JRE AU client installed fails update to NEXTVER on Mac 10.11

A new installer is introduced in the 8u65 release to update OS X users to the latest version. The installer will apply to both scheduled and manual updates, and bundles made available on java.com and OTN. Users who experience compatibility issues with the new installer can manually download and install the ".pkg" installer available on My Oracle Support.

VM crash when class is redefined with Instrumentation.redefineClasses

The JVM could crash when a class was redefined with Instrumentation.redefineClasses(). The crash could either be a segmentation fault at SystemDictionary::resolve_or_null, or an internal error with the message "tag mismatch with resolution error table". This has now been fixed.

See JDK-8076110.

Known Issues

[macosx] Sponsor offer screen accessibility (a11y) issues

Users who operate the keyboard to access user interfaces in the Java installer will be unable to access hyperlinks and checkboxes in software add-on offer screens. As a workaround to setting preferences related to add-on software in the user interface, users can disable such offers either by disabling them in the Java Control Panel, or by passing 'SPONSORS=0' via the command line. For more information, refer to: https://www.java.com/en/download/faq/disable_offers.xml

The Java SE 8u60 Advanced Platform, available for Java SE Subscription customers, is based on the current Java SE 8u60 release. 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 Suite and Java SE Advanced, visit Java SE Products Overview.

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

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

The following sections summarize changes made in all Java SE 8u60 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 8u60 b32

 

Bug Fixes

BugId Category Subcategory Description
8081297
(Confidential)
security-libs javax.net.ssl Unable to process PreMasterSecret Tomcat issue
8132082 security-libs javax.net.ssl Let OracleUcrypto accept RSAPrivateKey
8075773 core-svc tools jps running as root fails after the fix of JDK-8050807
8133943
(Confidential)
hotspot gc Better TLAB handling for Resource Management
8134719
(Confidential)
hotspot gc Reduce locking at native layer when thread metrics are updated due to resource context switch at thread level
8134109 deploy plugin Applet2Manager.getMainDeploymentRuleSet ignores jar version.
8133196 core-libs java.net HTTPS hostname invalid issue with InetAddress

Changes in Java SE 8u60 b31

Please note that fixes from prior BPR (8u51 b31) are included in this BPR.

Java™ SE Development Kit 8, Update 60 (JDK 8u60)

The full version string for this update release is 1.8.0_60-b27 (where "b" means "build"), except for OS X, where the version string is 1.8.0_60-b28. The version number is 8u60.

Highlights

This update release contains several enhancements and changes including the following:

IANA Data 2015e

JDK 8u60 contains IANA time zone data version 2015e. 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 8u60 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_51
7 1.7.0_85
6 1.6.0_101

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u60) will expire with the release of the next critical patch update scheduled for October 20, 2015.

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

Java SE Development Kit for ARM Release 8u60

This release includes Java Development Kit for ARM Release 8u60 (JDK 8u60 for ARM).

For ARM device support information, see Java SE Development Kit Downloads page.

For system requirements, installation instructions and troubleshooting tips, see Installation Instructions page.

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

XX:NativeMemoryTracking=summary

Notes

deploy
New "Use roaming profile" option added in Java Control Panel (Windows only)
New option "Use roaming profile" added in JCP (Windows only).

1. The option is set when file <user_home>\AppData\Roaming\Sun\Java\Deployment\deployment.properties exists.

2. Setting this option in JCP results in deployment.properties file from LocalLow being copied to the Roaming folder.

3. Clearing this option results in the deployment.properties file being moved from the Roaming folder to the LocalLow folder.
 

When the option is set, the following data is stored in the roaming profile:

1. deployment.properties
2. local application properties
3. security baselines
4. blacklisted certs
5. blacklisted jars
6. user certs stores
7. exception site list

The rest of the cache ( the cache without LAP), temp and log folders are always stored in LocalLow regardless of the roaming profile settings.
JDK-8062830 (not public)

Different bytecode between JDK8u45 and JDK8u60
Fixing JDK-8064857 has provoked a benign, actually beneficial, side effect in javac's code generation. The mentioned fix has improved the information javac has about aliveness of local variables and thus jump chains have richer information allowing the compiler to generate direct jumps to the final destination when in the past a chain of intermediate jumps were generated.
See JDK-8080555.

New Features and Changes

IBM1166 character set now available
This release adds IBM1166 character set. It provides support for cyrillic multilingual with euro for Kazakhstan. Aliases for this new character set include cp1166,ibm1166, ibm-1166, and 1166.
See JDK-8071447.

Allow use of TransmitFile on Microsoft Windows
Applications running on server editions of Microsoft Windows that make heavy use of java.nio.channels.FileChannel.transferTo may see performance improvements if the implementation uses TransmitFile. TransmitFile makes use of the Windows cache manager to provide high-performance file data transfer over sockets. The system property jdk.nio.enableFastFileTransfer controls whether the JDK uses TransmitFile on Microsoft Windows. It is disabled by default but can be enabled by setting the system property on the command line with -Djdk.nio.enableFastFileTransfer or -Djdk.nio.enableFastFileTransfer=true.
See JDK-8064407.

Allow use of SIO_LOOPBACK_FAST_PATH on Microsoft Windows
Applications running on server editions of Microsoft Windows that make heavy use of loopback connections may see latency and performance improvements if SIO_LOOPBACK_FAST_PATH is enabled. The system property jdk.net.useFastTcpLoopback controls whether the JDK enables SIO_LOOPBACK_FAST_PATH on Microsoft Windows. It is disabled by default but can be enabled by setting the system property on the command line with -Djdk.net.useFastTcpLoopback or -Djdk.net.useFastTcpLoopback=true.
See JDK-8060170.

G1 now collects unreachable Humongous objects during young collections
G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references.

Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled.


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

  • Addition:
    In the previous section, we mentioned that every JavaScript object when exposed to Java APIs implements the java.util.Map interface. This is true even for JavaScript arrays. However, this behavior is often not desired or expected when the Java code expects JSON-parsed objects. Java libraries that manipulate JSON-parsed objects usually expect arrays to expose the java.util.List interface instead. If you need to expose your JavaScript objects so that arrays are exposed as lists and not maps, you can use the Java.asJSONCompatible(obj) function, where obj is the root of your JSON object tree.

  • Correction:
    The caution mentioned at the end of Mapping Data Types section, is no longer applicable.

    Nashorn ensures that internal JavaScript strings are converted to java.lang.String when exposed externally.

  • Correction:
    The statement in the section Mapping Data Types, that mentions "For example, arrays must be explicitly converted,........." is not correct.

    Arrays are automatically converted to Java array types, such as java.util.List, java.util.Collection, java.util.Queue and java.util.Deque and so on.

Changes in Deployment Rule Set v1.2
JDK 8u60 implements Deployment Rule Set (DRS) 1.2, which includes the following changes:

  • Add "checksum" element as sub element of "id" which can allow unsigned jars to be identified by the SHA-256 checksum of the uncompressed form of a jar:

    • The "checksum" element will match only unsigned jars, and the given hash will be compared only against the uncompressed form of the jar.
    • The "checksum" element (similar to "certificate" element) has two arguments "hash" and "algorithm", however, unlike "certificate" element, the only supported value for "algorithm" is "SHA-256". Any other value provided will be ignored.
  • Allow "message" element to apply to all rule types, where previously it only applied to a block rule:

    • In a run rule, a message sub element will cause a message dialog to be displayed where without a run rule, the default behavior would be to show certificate or unsigned dialog. The message will be displayed in the message dialog.
    • In a default rule, the message will only be displayed if the default action is to block. In such a case the message will be included in the block dialog.
  • Echo "customer" blocks in the Java Console, trace files, and Java Usage Tracker records.

    • Previous to DRS 1.2, "customer" elements could be included (with any sub-elements) in the ruleset.xml file. This element and all its sub elements are ignored. In DRS 1.2, the elements are still functionally ignored. However:
      • When parsing the ruleset.xml file, all "customer" blocks will be echoed to the Java Console and deployment trace file (if Console and Tracing are enabled).
      • When using a rule, all "customer" records included within that rule will be added to the Java Usage Tracker (JUT) record (if JUT is enabled).
  • As a result of the above changes, the DTD for DRS 1.2 is as follows:

    
    <!ELEMENT ruleset (rule*)>
    <!ATTLIST ruleset href CDATA #IMPLIED>
    <!ATTLIST ruleset version CDATA #REQUIRED>
    
    <!ELEMENT rule (id, action)>
    
    <!ELEMENT id (certificate?, checksum?) >
    <!ATTLIST id title CDATA #IMPLIED>
    <!ATTLIST id location CDATA #IMPLIED>
    
    <!ELEMENT certificate EMPTY>
    <!ATTLIST certificate algorithm CDATA #IMPLIED>
    <!ATTLIST certificate hash CDATA #REQUIRED>
    
    <!ELEMENT checksum EMPTY>
    <!ATTLIST checksum algorithm CDATA #IMPLIED>
    <!ATTLIST checksum hash CDATA #REQUIRED>
    
    <!ELEMENT action (message?)>
    <!ATTLIST action permission (run | block | default) #REQUIRED>
    <!ATTLIST action version CDATA #IMPLIED>
    <!ATTLIST action force (true|false) "false">
    
    <!ELEMENT message (#PCDATA)>
    <!ATTLIST message locale CDATA #IMPLIED>
    
    
    

Bug Fixes

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

The following are some of the notable bug fixes included in JDK 8u60 release:

Area: hotspot/ compiler
Synopsis: Nondeterministic wrong answer on arithmetic corrected
When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed.

See JDK-8072753.

Area: security-libs/org.ietf.jgss:krb5
Synopsis: dns_lookup_realm should be false by default

The dns_lookup_realm setting in Kerberos' krb5.conf file is by default false.

See 8080637.

Area: security-libs/javax.net.ssl
Synopsis: Disable RC4 cipher suites

RC4-based TLS ciphersuites (e.g. TLS_RSA_WITH_RC4_128_SHA) are now considered compromised and should no longer be used (see RFC 7465). Accordingly, RC4-based TLS ciphersuites have been deactivated by default in the Oracle JSSE implementation by adding "RC4" to "jdk.tls.disabledAlgorithms" security property, and by removing them from the default enabled ciphersuites list. These cipher suites can be reactivated by removing "RC4" form "jdk.tls.disabledAlgorithms" security property in the java.security file or by dynamically calling Security.setProperty(), and also readding them to the enabled ciphersuite list using the SSLSocket/SSLEngine.setEnabledCipherSuites() methods.

You can also use the -Djava.security.properties command line option to override the jdk.tls.disabledAlgorithms security property. For example:

java -Djava.security.properties=my.java.security ...

where my.java.security is a file containing the property without RC4:

jdk.tls.disabledAlgorithms=SSLv3

Even with this option set from commandline, the RC4 based ciphersuites need to be re-added to the enabled ciphersuite list by using the SSLSocket/SSLEngine.setEnabledCipherSuites() methods.

See 8076221.

Area: security-libs/java.secuirty
Synopsis: Support keystore type detection for JKS and PKCS12 keystores

Keystore Compatibility Mode:
To aid interoperability, the Java keystore type JKS now supports keystore compatibility mode by default. This mode enables JKS keystores to access both JKS and PKCS12 file formats. To disable keystore compatibility mode set the Security property keystore.type.compat to the string value false.

See 8062552.

Area: core-libs/java.lang
Synopsis: Deprecate Unsafe monitor methods in JDK 8u release

The methods monitorEnter, monitorExit and tryMonitorEnter on sun.misc.Unsafe are marked as deprecated in JDK 8u60 and will be removed in a future release. These methods are not used within the JDK itself and are very rarely used outside of the JDK.

See 8069302.

Area: hotspot/jfr
Synopsis: Extract JFR recording from the core file using SA

DumpJFR is a Serviceability Agent based tool that can be used to extract Java Flight Recorder(JFR) data from the core files and live Hotspot processes. DumpJFR can be used in one of the following methods:

  • Attach DumpJFR to a live process:

    java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>

  • Attach DumpJFR to a core file:

    java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>

DumpJFR tool dumps the JFR data to a file called recording.jfr in the current working folder. 8065301(not public).

Area: tools/javac
Synopsis: Local variables named 'enum' lead to spurious compiler crashes

The javac parser is incorrectly parsing local variables with name 'enum'; this results in spurious failures when a program containing such local variables is compiled with a 'source' flag corresponding to a release in which the enum construct is not available (such as '-source 1.4').

See 8069181.

Known Issues

Area: auto-update (OS X 10.11+ only)
Synopsis: Auto-update error when auto-updating to earlier versions
A change in OS X 10.11 caused the auto-update mechanism to fail when a system running OS X 10.11 is auto-updated from versions 8u40 through 8u60 build 27, inclusive.  This issue was addressed in 8u60 build 28 and later. The issue only appears when a JRE release between 8u40 and 8u60 b27 has been installed on Mac OS X 10.11 and is then used to trigger an auto-update sequence. Impacted machines would appear to go through the update flow but at the end of the process the newer JRE would not be installed, the older JRE would remain, and therefore the auto-update mechanism would continue prompting the user to update. Workaround: Manually install a JRE version 8u60 b28 or higher into the affected system.

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

The following sections summarize changes made in all Java SE 8u51 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 8u51 b34

Bug Fixes

BugId Category Subcategory Description
8067422 tools javac Lambda method names are unnecessarily unstable

Changes in Java SE 8u51 b31

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

Java™ SE Development Kit 8, Update 51 (JDK 8u51)

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

Highlights

This update release contains several enhancements and changes including the following:

IANA Data 2015d

JDK 8u51 contains IANA time zone data version 2015d. 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 8u51 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_51
7 1.7.0_85
6 1.6.0_101

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u51) will expire with the release of the next critical patch update scheduled for October 20, 2015.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u51) on November 20, 2015. After either condition is met (new release becoming available or expiration date reached), 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 and Changes

Ephemeral DH keys less than 768 bits deactivated
Ephemeral DH keys less than 768 bits are deactivated in JDK. New algorithm restriction DH keySize < 768 is added to Security Property jdk.tls.disabledAlgorithms.

JDK-8076328 (not public).


Operating system's restricted environment (Native Sandbox)

JDK 8u51 introduced the following changes to Native Sandbox:

  • Native sandbox is available on Windows platform only.

  • Native sandbox can be enabled or disabled through Java Control Panel->Advanced settings->Enable the operating system's restricted environment (native sandbox) or by setting deployment.security.use.native.sandbox property to true in deployment.properties file.

    Native sandbox is disabled by default.

  • When native sandbox is enabled, the sandbox applets or web-start applications will run in a restricted environment, that is provided by the operating system. This will not affect the all-permission applications and they will continue to run as before.

  • Native sandbox will be disabled for applications included the in Exception Site List (ESL) or when Deployment Rule Set (DRS) is used.

  • Sandbox applets deployed with HTML applet tag which includes all-permissions JAR files from the Class-Path manifest attribute, will run in native sandbox.

    In such cases, a special warning dialog will display, informing the user that the applet may not work properly, when such an applet tries to access the all-permission JAR files.

  • Custom preloader will be disabled in certain cases when native sandbox is enabled:

    • Custom preloader will be disabled when sandbox applets or web-start applications are initializing and the default preloader will be used instead. After application is initialized, Java VM restarts with native sandbox enabled and the custom preloader will be used.
    • For all-permission applications, custom preloader will be disabled if it is located in the JNLP file with sandbox permission, until user agrees to run application from the Security Dialog, which grants unrestricted access (privileged) to application.

Bug Fixes

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

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

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

Area: security-libs/java.security
Synopsis: Add new Comodo roots to root CAs

Four new root certificates have been added for Commodo:


1. COMODO ECC Certification Authority
    alias: comodoeccca
    DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, 
    ST=Greater Manchester, C=GB

2. COMODO RSA Certification Authority
    alias: comodorsaca
    DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, 
    ST=Greater Manchester, C=GB

3. USERTrust ECC Certification Authority
    alias: usertrusteccca
    DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, 
    L=Jersey City, ST=New Jersey, C=US

4. USERTrust RSA Certification Authority
    alias: usertrustrsaca
    DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, 
    L=Jersey City, ST=New Jersey, C=US

JDK-8077652 (not public)

Area: security-libs/java.security
Synopsis: Add new GlobalSign roots to root CAs

Two root certificates have been added for GlobalSign:


1. GlobalSign ECC Root CA - R4
   alias: globalsigneccrootcar4
   DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4

2. GlobalSign ECC Root CA - R5
   alias: globalsigneccrootcar5
   DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5

JDK-8077653 (not public)

Area: security-libs/java.security
Synopsis: Add Actalis to root CAs

Added one new root certificate:

Actalis Authentication Root CA
   alias: actalisauthenticationrootca
   DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, 
   L=Milan, C=IT 

JDK-8077651 (not public)

Area: security-libs/java.security
Synopsis: Add new Entrust ECC root

Added one new root certificate:

Entrust Root Certification Authority - EC1
  alias: entrustrootcaec1
  DN: CN=Entrust Root Certification Authority - EC1, 
  OU="(c) 2012 Entrust, Inc. - for authorized use only", 
  OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

JDK-8072961 (not public)

Area: security-libs/java.security
Synopsis: Remove old Valicert Class 1 and 2 Policy roots

Removed two root certificates with 1024-bit keys:

  
1. ValiCert Class 1 Policy Validation Authority
      alias: secomvalicertclass1ca
      DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, 
      OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", 
      L=ValiCert Validation Network

  2. ValiCert Class 2 Policy Validation Authority
      alias: valicertclass2ca
      DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, 
      OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", 
      L=ValiCert Validation Network

JDK-8077354 (not public)

Area: security-libs/java.security
Synopsis: Remove old Thawte roots

Removed two root certificates with 1024-bit keys:

1. Thawte Server CA
    alias: thawteserverca
    DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, 
    OU=Certification Services Division, O=Thawte Consulting cc, 
    L=Cape Town, ST=Western Cape, C=ZA

2. Thawte Personal Freemail CA
    alias: thawtepersonalfreemailca
    DN: EMAILADDRESS=personal-freemail@thawte.com, 
    CN=Thawte Personal Freemail CA, OU=Certification Services Division, 
    O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA

JDK-8073271 (not public)

Area: security-libs/java.security
Synopsis: Remove more old Verisign, Equifax, and Thawte roots

Removed five root certificates with 1024-bit keys:


1. Verisign Class 3 Public Primary Certification Authority - G2
    alias: verisignclass3g2ca
    DN: OU=VeriSign Trust Network, 
    OU="(c) 1998 VeriSign, Inc. - For authorized use only", 
    OU=Class 3 Public Primary Certification Authority - G2, 
    O="VeriSign, Inc.", C=US

2. Thawte Premium Server CA
    alias: thawtepremiumserverca
    DN: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, 
    OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, 
    ST=Western Cape, C=ZA

3. Equifax Secure Certificate Authority
    alias: equifaxsecureca
    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US

4. Equifax Secure eBusiness CA-1
    alias: equifaxsecureebusinessca1
    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US

5. Equifax Secure Global eBusiness CA-1,
    alias: equifaxsecureglobalebusinessca1
    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US

JDK-8075091 (not public)

Area: security-libs/java.security
Synopsis: Remove TrustCenter CA roots from cacerts

Removed three root certificates:


1. TC TrustCenter Universal CA I
    alias: trustcenteruniversalcai
    DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, 
    O=TC TrustCenter GmbH, C=DE

2. TC TrustCenter Class 2 CA II
    alias: trustcenterclass2caii
    DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, 
    O=TC TrustCenter GmbH, C=DE

3. TC TrustCenter Class 4 CA II
    alias: trustcenterclass4caii
    DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, 
    O=TC TrustCenter GmbH, C=DE

JDK-8071699 (not public)

Area: security-libs/javax.net.ssl
Synopsis: Deprecate RC4 in SunJSSE provider

RC4 is now considered as a weak cipher. Servers should not select RC4 unless there is no other stronger candidate in the client requested cipher suites. A new security property, jdk.tls.legacyAlgorithms, is added to define the legacy algorithms in Oracle JSSE implementation. RC4 related algorithms are added to the legacy algorithms list.

JDK-8043201 (not public)

Area: security-libs/javax.net.ssl
Synopsis: Prohibit RC4 cipher suites

RC4 is now considered as a compromised cipher. RC4 cipher suites have been removed from both client and server default enabled cipher suite list in Oracle JSSE implementation. These cipher suites can still be enabled by SSLEngine.setEnabledCipherSuites() and SSLSocket.setEnabledCipherSuites() methods.

JDK-8043202 (not public)

Area: security-libs/javax.net.ssl
Synopsis: Improved certification checking

With this fix, JSSE endpoint identification does not perform reverse name lookup for IP addresses by default in JDK.

If an application does need to perform reverse name lookup for raw IP addresses in SSL/TLS connections, and encounter endpoint identification compatibility issue, System property "jdk.tls.trustNameService" can be used to switch on reverse name lookup. Note that if the name service is not trustworthy, enabling reverse name lookup may be susceptible to MITM attacks.

JDK-8067694 (not public)

Known Issues

Area: deploy/plugin
Synopsis: Java issue with Firefox 38, long delay with MyD loading

Java Plugin is unable to obtain proxy settings from Firefox 38 due to a bug in Mozilla framework. It may cause a long delay during RIA start up or can even cause start up failures. See the related issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=1165286

According to Mozilla, Firefox 39 will contain a fix for this problem.

Workarounds:

  • Use another supported browser
  • Downgrade browser to Firefox 37
  • Specify proxy settings in JCP (NOT in "Browser settings")

JDK-8081459 (not public)


Area: deploy
Synopsis: JNLP files won't launch from IE11 on Windows 10 Creators Update

Web-start applications cannot be launched when clicking JNLP link from IE 11 on Windows 10 Creators Update when 64-bit JRE is installed. Workaround is to uninstall 64-bit JRE and use only 32-bit JRE.

See JDK-8185661.

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

The following sections summarize changes made in all Java SE 8u45 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 8u45 b37

Bug Fixes

BugId Category Subcategory Description
8085965 hotspot gc VM hangs in C2Compiler
8075210 hotspot gc Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap
8074037 hotspot gc Refactor the G1GCPhaseTime logging to make it easier to add new phases
8061630 hotspot gc G1 iterates over JNIHandles two times
8067655 hotspot gc Clean up G1 remembered set oop iteration
8051837 hotspot gc Remove temporary G1UseParallelRSetUpdating and G1UseParallelRSetScanning flags
8072384 core-libs java.net Setting IP_TOS on java.net sockets not working on unix

Changes in Java SE 8u45 b36

Bug Fixes

BugId Category Subcategory Description
8072999 deploy webstart DRS certificate based rule does not match with Java WS Application compressed by pack200
8076220
(Confidential)
deploy plugin If checksum rule is specified drs tries to calculate checksum for folder (DRS1.2)
8069161 deploy plugin Slow cache performance since JRE 7u06
8072619
(Confidential)
deploy plugin OutOfMemoryError in Java Plugin for IE
8076189
(Confidential)
install install Update Makefiles to Roll a .dmg File for the .pkg Installer
8080288
(Confidential)
deploy plugin Applet failed to reload after "javaws -uninstall"
8072676 client-libs javax.swing [macosx] Jtree icon painted over label when scrollbars present in window
8079223 deploy   unnecessary performance degradation caused by fix to JDK-8052111
8077155 core-libs java.net LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection

Changes in Java SE 8u45 b33

Bug Fixes

BugId Category Subcategory Description
8073072
(Confidential)
deploy plugin 8u25-b31/8u31-b32 fails to evaluate proxy pac file for some URLs
8073008 client-libs java.awt press-and-hold input method for accented characters works incorrectly on OS X

Changes in Java SE 8u45 b32

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

Java™ SE Development Kit 8, Update 45 (JDK 8u45)

The full version string for this update release is 1.8.0_45-b14 (where "b" means "build") except for Windows, where the version string is 1.8.0_45-b15. The version number is 8u45.

IANA Data 2015a

JDK 8u45 contains IANA time zone data version 2015a. 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 8u45 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_45
7 1.7.0_79
6 1.6.0_95
5.0 1.5.0_85

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u45) will expire with the release of the next critical patch update scheduled for July 14, 2015.

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

Blacklist Entries

A new blacklist entry is included in this release.

For more details on the entry, see the related Cisco Security Advisory.

Bug Fixes

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

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

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

Area: tools/jar
Synopsis: Improve jar file handling

Starting with JDK 8u45 release, the jar tool no longer allows the leading slash "/" and ".." (dot-dot) path component in zip entry file name when creating new and/or extracting from zip and jar file. If needed, the new command line option "-P" should be used explicitly to preserve the dot-dot and/or absolute path component.

See 8064601 (not public).

Area: deploy/webstart
Synopsis: jnlp app with nested "resource" section fails with NPE on load in jre8u40

A jnlp application, with nested <resources> tags within a <java> or <j2se> tag, can throw an NPE. The issue is now fixed. The <resources> tag should be used only if the <java> is actually used.

See 8072631 (not public).

Known Issues

Area: core-libs/jdk.nashorn
Synopsis: Finally blocks inlined incorrectly.

Nashorn has known issues where it incorrectly compiles try/finally constructs. For more information on this issue and a workaround, see Try/finally compilation issues wiki page.

See 8067139.

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

The following sections summarize changes made in all Java SE 8u40 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 8u40 b32

Please note that fixes from prior BPR (8u31 b33) are included in this BPR.

Bug Fixes

BugId Category Subcategory Description
8071897 deploy webstart JRE 8U25 and 8u31 b32 cannot launch Java Web Start with proxy pac but works fine for 7u67
8066436
(Confidential)
client-libs java.awt Minimize can cause window to disappear on osx

Java™ SE Development Kit 8, Update 40 (JDK 8u40)

The full version string for this update release is 1.8.0_40-b26 (where "b" means "build") except for OS X, where the version string is 1.8.0_40-b27. The version number is 8u40.

Highlights

This update release contains several enhancements and changes including the following:

IANA Data 2014j

JDK 8u40 contains IANA time zone data version 2014j. 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 8u40 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_31
7 1.7.0_75
6 1.6.0_91
5.0 1.5.0_81

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u40) will expire with the release of the next critical patch update scheduled for April 14, 2015.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u40) on May 14, 2015. After either condition is met (new release becoming available or expiration date reached), 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 and Changes

Java Packager Tool Enhancements
JDK 8u40 release contains the following enhancements to the Java Packager:


Deprecated APIs
The endorsed-standards override mechanism and the extension mechanism are deprecated and may be removed in future releases. There are no runtime changes. Existing applications using the 'endorsed-standards override' or 'extension' mechanisms are recommended to migrate away from using these mechanisms. To help identify any existing uses of these mechanisms, the -XX:+CheckEndorsedAndExtDirs command-line option is available. It will fail if any of the following conditions is true:

  • -Djava.endorsed.dirs or -Djava.ext.dirs system property is set to alter the default location; or
  • ${java.home}/lib/endorsed directory exists; or
  • ${java.home}/lib/ext contains any JAR files excluding the ones that JDK ships or
  • any platform-specific system-wide extension directory contains any JAR files.

The -XX:+CheckEndorsedAndExtDirs command-line option is supported in JDK 8u40 and later releases.

Multiple JRE Launcher feature Deprecated

The Launch-Time JRE Version Selection or the Multiple JRE Launcher feature is deprecated in JDK 8u40. Visit http://openjdk.java.net/jeps/231 for further information. Applications that require specific Java versions deployed using this feature must switch to alternate deployment solutions such as Java WebStart.

JJS Tool Page Differences

The Japanese version of the jjs help page is different from the English version. Some of the unsupported options have been removed from the English version of the jjs tool page. The Japanese version of document will be updated in future.

See 8062100 (not public).

For other jjs tool page changes, see Tools Enhancements in JDK 8.

Java SE Tools Updated

Java SE tools have been updated. See Tools Enhancements in JDK 8 for details.

Change in default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent

The default value for G1HeapWastePercent was changed from 10 to 5 to reduce the need for full GCs. For the same reason the default value for G1MixedGCLiveThresholdPercent was changed from 65 to 85.

Nashorn Enhancements

The new jdk.nashorn.api.scripting.ClassFilter interface enables you to restrict access to specified Java classes from scripts run by a Nashorn script engine. See Restricting Script Access to Specified Java Classes in the Nashorn User's Guide and 8043717 (not public) for more information.

The Nashorn compiler now has static type inference capabilities for local variables and expressions. While JavaScript is hard to analyze statically, Nashorn is able to generate code optimized for specific types.

Nashorn now supports optimistic typing, which complements static type inference. For types that can't be statically inferred, Nashorn will make optimistic assumptions and gradually deoptimize when assumptions turn out to be wrong. To activate this feature use the --optimistic-types=true option. See Nashorn Architecture and Performance Improvements for more information.

Function.prototype.bind and Function.prototype.call are enhanced to work on everything that can be invoked in Nashorn, such as POJO methods, instances of @FunctionalInterface classes.

Issues with Third party's JCE Providers

The fix for JDK-8023069 (in JDK 8u20) updated both the SunJSSE and and SunJCE providers, including some internal interfaces.

Some third party JCE providers (such as RSA JSAFE) are using some sun.* internal interfaces, and therefore will not work with the updated SunJSSE provider. Such providers will need to be updated in order for them to work with the updated SunJSSE provider.

If you have been impacted by this issue, contact your JCE vendor for an update.

See 8058731.

Message digest algorithms are now enabled by default for SunPKCS11 provider on Solaris

If you are using Solaris 10, a change was made to re-enable operations with MD5, SHA1, and SHA2 through the Solaris Crypto Framework. If you experience a CloneNotSupportedException or PKCS11 error CKR_SAVED_STATE_INVALID message with JDK 8u40, you should verify and apply the following patches or newer versions of them:

  • 150531-02 on sparc
  • 150636-01 on x86

See 8037745.

Troubleshooting Guide Updates for NMT, JMC, and JFR

The Native Memory Tracking (NMT) is a Java Hotspot VM feature that tracks internal memory usage for a HotSpot JVM. Native Memory Tracking can be used to monitor VM internal memory allocations and diagnose VM memory leaks.

VM enhancements page is updated with NMT features. See Java Virtual Machine Enhancements in Java SE 8.

Troubleshooting Guide is updated with NMT features. See Native Memory Tracking.

Troubleshooting Guide is also updated with content for Troubleshooting using Java Mission Control, Debug Memory Leaks using Java Flight Recorder (JFR), and Troubleshooting Performance Issues using JFR.

JavaFX Enhancements

Starting with JDK 8u40 release, JavaFX controls are enhanced to support assistive technologies, meaning that JavaFX controls are now accessible. In addition, a public API is provided to allow developers to write their own accessible controls.

Accessibility support is provided on Windows and Mac OS X platforms and includes:

  • Support for reading JavaFX controls by a screen reader
  • JavaFX controls are traversable using the keyboard
  • Support for a special high-contrast mode that makes controls more visible to users.

See 8043344 (not public).

JDK 8u40 release includes new JavaFX UI controls; a spinner control, formatted-text support, and a standard set of alert dialogs.

See 8043350 (not public).

Commercial Features

  • Application Class Data Sharing (AppCDS):

    Application Class Data Sharing (AppCDS) extends CDS (see Class Data Sharing) to enable you to place classes from the standard extensions directories and the application class path in the shared archive. This is an experimental feature and not licensed for commercial use. See the -XX:+UseAppCDS option in the java launcher tool page.

  • Cooperative Memory Management:

    Starting with JDK 8u40, the notion of "memory pressure" has been added to the JDK. Memory pressure is a property that represents the total memory usage (RAM) on the system. The higher the memory pressure, the closer the system is to running out of memory.  This is an experimental feature and not licensed for commercial use.

    As a reaction to increased memory pressure, the JDK will try to reduce its memory usage. This is mainly done by reducing the Java heap size. The actions the JDK will take to reduce memory usage may lead to reduced performance. This is an intentional choice.

    The pressure level is provided by the application through a JMX MXBean using a scale from 0 (no pressure) to 10 (almost out of memory). To enable this feature, the jdk.management.cmm.SystemResourcePressureMXBean should be registered. The memory pressure is then set using the "MemoryPressure" attribute.

    A new command line flag -XX:MemoryRestriction that takes one of the arguments 'none', 'low', 'medium', or 'high', is also available. This flag will set the initial pressure in the JDK and will work also in cases where the MXBean is not registered.

    Cooperative Memory Management requires the G1 GC (-XX:+UseG1GC). This feature is not compatible with the flag -XX:+ExplicitGCInvokesConcurrent.

  • New Commercial Flags:

    Two new VM options are now available for commercial license holders:

    • -XX:+ResourceManagement
    • -XX:ResourceManagementSampleInterval=value (milliseconds)

    For more information, see Java Launcher documentation.

  • Java Flight Recorder(JFR) Enhancements

    It is now possible to enable Java Flight Recorder at runtime. For details, see the Java Flight Recorder Runtime Guide at http://docs.oracle.com/javacomponents/jmc-5-5/jfr-runtime-guide/index.html.

  • New MSI Installer Documentation:

    The Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide is available at https://docs.oracle.com/javacomponents/msi-jre8/install-guide. The MSI Enterprise JRE Installer requires a commercial license for use in production. To learn more about commercial features and how to enable them, visit https://www.oracle.com/technetwork/java/javaseproducts/overview/index.html.


Bug Fixes


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

The following are some of the notable bug fixes included in JDK 8u40 release:

Area: core-svc
Synopsis: Default and static interface methods in JDI, JDWP and JDB

Since JDK 8 it is possible to have directly executable static and default methods in interfaces. These methods are not executable via JDWP or JDI and therefore can not be properly debugged. See JDK 8 Compatibility Guide for more details.

See 8042123.

Area: install
Synopsis: Java Access Bridge can be enabled from Control panel for 32 bit JREs.

Previously the "Enable Java Access Bridge" check box got removed from the Java Control Panel with 64 bit JRE uninstall even when 32 bit JRE was still present on the system.

Starting with JDK 8u40 release, the "Enable Java Access Bridge" checkbox is retained, at Control Panel -> Ease of Access -> Ease of Access Center -> Use the computer without a display, if a 32 bit jre is present. So, a user can enable Java Access bridge via control panel for 32 bit JREs.

See 8030124.

Area: client-libs
Synopsis: Modernizing the JavaFX Media Stack on Mac OS X

An AVFoundation based player platform is added to JavaFX media. The old QTKit based platform is now removable for Mac App Store compatibility.

See 8043697 (not public).

Area: deploy/plugin
Synopsis: Missing DOM APIs

In JDK 8u40 release, the old plugin DOM APIs were inadvertently removed. If an applet requires the use of com.sun.java.browser.dom.DOMService to communicate with the browser, then users may need to update their applet to use netscape.javascript.JSObject or continue using JDK 8 Update 31.

This issue has been resolved in build 26 and new 8u40 installers have been posted. If you are experiencing this problem, download and run the updated JDK 8u40 installers.

See 8074564.

Area: client-libs/java.awt
Synopsis: Mac 10.10: Application run with splash screen has focus issues

Applications started through webstart or standalone applications, which use splash screen, cannot get keyboard focus.

Workaround: Launch javaws using the -Xnosplash option.

This issue has been resolved in build 27 and a new 8u40 installer has been posted. If you are experiencing this problem, download and run the updated JDK 8u40 installer.

See 8074668.

Known Issues


JDK

Area: hotspot/gc
Synopsis: Performance degradation on G1 on Solaris when large pages are requested

When using G1 on Solaris where large pages are requested, the VM does not always use large pages when it could. This may result in significant throughput degradation, particularly on the Solaris x64 platform.

See 8058354.

Area: hotspot/compiler
Synopsis: Nondeterministic arithmetic when converting long strings to integers and performing OSR

For JRE 6 and above, when performing OSR on loops with huge stride and/or initial values, in a very rare case the tiered/server compilers can produce non-canonical loop shapes that can produce nondeterministic answers, when answers should be deterministic.

Workaround: Launch Java using the -XX:-UseOnStackReplacement flag.

See 8072753.

JavaFX

Area: Control
Synopsis: Behavior and access of Control#getUserAgentStylesheet method changed in 8u40.

In JDK 8u40, the getUserAgentStylesheet() method moved from the Control class to the Region superclass.

The method was promoted from protected to public, which preserves binary compatibility, but breaks source compatibility for subclasses of Control that override this method. The solution is to make the overridden method public in the subclass of Control.

The semantics of the method are also changed such that any CSS that is applied from CSS files imported via the getUserAgentStylesheet() method is only applied to the Region in which it is a user agent stylesheet. Previously, a CSS file imported in this way could make changes throughout the application user interface, which could result in unintended style clobbering. This is no longer possible from JDK 8u40 onwards, and applications which might have been relying on this unintended behavior, may see differences in styling as a result.

See RT-38640.

Area: Control
Synopsis: PopupControl$CSSBridge changed to extend Pane in 8u40.

In JDK 8u40, the object inheritance hierarchy of the protected javafx.scene.control.PopupControl$CSSBridge inner class has changed in an incompatible manner. Prior to JDK 8u40, PopupControl$CSSBridge extended from Group and now it extends from Pane.

This is primarily an internal class for custom PopupControls such as Tooltip, but it is possible that a third-party control might subclass this class. Such applications that subclass PopupControl$CSSBridge might be affected if they were calling or overriding methods in Group that are not in Pane.

See RT-33696.

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

The following sections summarize changes made in all Java SE 8u31 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 8u31 b33

Bug Fixes

BugId Category Subcategory Description
8062032
(Confidential)
deploy plugin Client certificate authentication issues with TLS 1.2 and browser keystore
8068283 client-libs java.awt Mac OS Incompatibility between JDK 6 and 8 regarding input method handling
8037417 deploy   javaws fails to launch app with empty href in jnlp file if Application-Library-Allowable-Codebase is used
8063047
(Confidential)
deploy webstart Need jnlp information from cached webstart application
8062375
(Confidential)
deploy webstart Warning message doesn't contain additional info: "Launched from downloaded JNLP file" when launched from shortcut or cache viewer
8037471 deploy deployment_toolkit The warning message displays the app name and publisher as "UNKNOWN" if cache is disabled

Changes in Java SE 8u31 b32

Bug Fixes

BugId Category Subcategory Description
8065858
(Confidential)
deploy plugin Applet doesn't load after upgrade to JDK 8u25

Changes in Java SE 8u31 b31

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

Bug Fixes

BugId Category Subcategory Description
8061648 deploy webstart JavaWS fails with proxy autoconfig due to missing "dnsResolve"

Java™ SE Development Kit 8, Update 31 (JDK 8u31)

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

Highlights

This update release contains several enhancements and changes including the following:


IANA Data 2014j

JDK 8u31 contains IANA time zone data version 2014j. 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 8u31 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_31
7 1.7.0_75
6 1.6.0_91
5.0 1.5.0_81

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u31) will expire with the release of the next critical patch update scheduled for April 14, 2015.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u31) on May 14, 2015. After either condition is met (new release becoming available or expiration date reached), 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 and Changes

SSLv3 is disabled by default

Starting with JDK 8u31 release, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not available by default. See the java.security.Security property jdk.tls.disabledAlgorithms in <JRE_HOME>/lib/security/java.security file.

If SSLv3 is absolutely required, the protocol can be reactivated by removing "SSLv3" from the jdk.tls.disabledAlgorithms property in the java.security file or by dynamically setting this Security property to "true" before JSSE is initialized.

It should be noted that SSLv3 is obsolete and should no longer be used.

Changes to Java Control Panel

Starting with JDK 8u31 release, SSLv3 protocol is removed from Java Control Panel Advanced options.

If the user needs to use SSLv3 for applications, re-enable it manually as follows:

  • Enable SSLv3 protocol on JRE level: as described in the previous section.
  • Enable SSLv3 protocol on deploy level: edit the deployment.properties file and add the following:


    deployment.security.SSLv3=true

Bug Fixes


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

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

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

The following sections summarize changes made in all Java SE 8u25 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 8u25 b32

Bug Fixes

BugId Category Subcategory Description
8061643 deploy webstart JavaWS fails with proxy autoconfig due to missing "resolve" permission

Changes in Java SE 8u25 b31

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

Java™ SE Development Kit 8, Update 25 (JDK 8u25)

The full version string for this update release is 1.8.0_25-b17 (where "b" means "build") except for Windows, where the version string is 1.8.0_25-b18 . The version number is 8u25.

IANA Data 2014c

JDK 8u25 contains IANA time zone data version 2014c. 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 8u25 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_25
7 1.7.0_71
6 1.6.0_85
5.0 1.5.0_75

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u25) will expire with the release of the next critical patch update scheduled for January 20, 2015.

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

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

Oracle recommends that users and developers disable use of the SSLv3 protocol. Please follow the Instructions to disable SSL v3.0 in Oracle JDK and JRE.

Unsafe Server Certificate Change in SSL/TLS Renegotiations Not Allowed.

Starting with JDK 8u25, unsafe server certificate change in SSL/TLS renegotiations is not allowed by default. Server certificate change in an SSL/TLS renegotiation may be unsafe and should be restricted:

  • if endpoint identification is not enabled in an SSL/TLS handshaking; and
  • if the previous handshake is a session-resumption abbreviated initial handshake; and
  • the identities represented by both certificates (in previous handshake and this handshake) cannot be regraded as the same.

If unsafe server certificate change is really required, please set the system property, jdk.tls.allowUnsafeServerCertChange, to "true" before JSSE is initialized. Note that this would re-establish the unsafe server certificate change issue.

Bug Fixes

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

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

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

Area: security-libs/javax.net.ssl
Synopsis: Decrease the preference mode of RC4 in the enabled cipher suite list

This fix decreases the preference of RC4 based cipher suites in the default enabled cipher suite list of SunJSSE provider.

See 8043200 (not public).

Area: client-libs
Synopsis: JRE 8u20 crashes while using Japanese IM on Windows

The VM crashes while using Swing controls when some Japanese or Chinese characters are input on Windows platform. The issue is now fixed.

See 8058858 (not public).

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

The following sections summarize changes made in all Java SE 8u20 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 8u20 b32

Bug Fixes

BugId Category Subcategory Description
8047288 client-libs java.awt [macosx] Endless loop in EDT on Mac

Changes in Java SE 8u20 b31

Please note that fixes from prior BPR (8u11 b31) are included in this BPR.

Bug Fixes

BugId Category Subcategory Description
8029837 xml jaxp NPE seen in XMLDocumentFragmentScannerImpl.setProperty since 7u40b33
8051012 hotspot runtime Regression in verifier for <init> method call from inside of a branch

Java™ SE Development Kit 8, Update 20 (JDK 8u20)

The full version string for this update release is 1.8.0_20-b26 (where "b" means "build"). The version number is 8u20.

Highlights

This update release contains several enhancements and changes including the following:

IANA Data 2014c

JDK 8u20 contains IANA time zone data version 2014c. 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 8u20 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_11
7 1.7.0_65
6 1.6.0_81
5.0 1.5.0_71

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u20) will expire with the release of the next critical patch update scheduled for October 14, 2014.

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

Java Mission Control

This JDK release includes Java Mission Control (JMC) version 5.4. For more information, see JMC 5.4 Release Notes.

Advanced Management Console (AMC) 1.0

Advanced Management Console (AMC) 1.0 is a commercial product available for Java users who license Java SE Advanced or Java SE Suite. AMC is downloaded separately from the JDK and is available to customers from My Oracle Support (MOS) or can be downloaded from OTN for trial purposes.

A primary benefit of Advanced Management Console is the ability to learn which applications are being run in the enterprise as well as the JREs that are being used. Additional information, such as the location of the application, vendor, permission level, number of JAR files and extensions, and number of times the application has been run is also provided. Information from Java Usage Tracker is collected by the AMC Collector, stored in the AMC database and displayed in the AMC UI.

Deployment rules can be created directly from this information and packaged into rule sets. The guided rule creation and packaging support greatly simplifies developing Deployment Rule Sets. The AMC UI can also be used to determine which rules and rule sets an application matches, helping system administrators understand the impact of installing a particular rule set prior to physically testing it in user environments.

For a summary of this feature, see Advanced Management Console documentation.

New Features and Changes

Changes to default methods affect the result of Class.getMethod and Class.getMethods

core-libs/java.lang:reflect

The javadoc for the Class.getMethod and Class.getMethods refer to the definition of inheritance in the Java Language Specification. Java SE 8 changed these rules in order to support default methods and reduce the number of redundant methods inherited from superinterfaces (see JLS 8, 8.4.8).

Class.getMethod and Class.getMethods were not updated with the 8 release to match the new inheritance definition (both may return non-inherited superinterface methods). Typically, the distinction is of no consequence; and for compatibility, it is preferred that the identity and number of returned methods match Java SE 7 as closely as possible. However, when the overriding method is a default method, it is important to filter out other overridden methods. As of 8u20, the implementation has been changed to perform this filtering step when the overrider is a default method.

See JDK-8029674.

sun.security.krb5.KdcComm interprets kdc_timeout as msec instead of sec

security-libs/org.ietf.jgss:krb5

An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s".

See JDK-8036779.

New flags added to Java Management API

The flags MinHeapFreeRatio and MaxHeapFreeRatio have been made manageable. This means they can be changed at runtime using the management API in Java. Support for these flags have also been added to the ParallelGC as part of the adaptive size policy.

Java Installer Changes

A new Microsoft Windows Installer (MSI) Enterprise JRE Installer which enables user to install the JRE across the enterprise, is available. See Downloading the Installer section in JRE Installation for Microsoft Windows for more information. The MSI Enterprise JRE Installer is only available as part of Java SE Advanced or Java SE Suite. For information about these commercial products, see Java SE Advanced and Java SE Suite.

The following new configuration parameters are added to support commercial features, for use by Java SE Advanced or Java SE Suite licensees only.

USAGETRACKER_CFG=

DEPLOYMENT_RULE_SET=

See Installing With a Configuration File for more information about these and other installer parameters.

The Java Uninstall Tool is integrated with the installer to provide an option to remove older versions of Java from the system. The change is applicable to 32 bit and 64 bit Windows platforms. See Uninstalling the JRE.

JRE Installation Directory

Starting with JDK 8u20 release, the JRE will be installed in a version specific directory. For example:

C:\Program Files\Java\jre1.8.0_20

The version specific directory naming is intentional and it does not indicate that the JRE install is static.

As with the earlier releases, static JRE install is performed only if STATIC=1 option is passed (via command line or config file) by the user.

Existing Java applications that depend on the physical location of the JRE should be updated to reflect the new installation directory format.

Java Control Panel Changes

The Update tab in the Java Control Panel now enables the users to automatically update 64-bit JREs (in addition to 32-bit versions) that are installed on their system.

The Medium security level has been removed. Now only High and Very High levels are available.

Applets that do not conform with the latest security practices can still be authorized to run by including the sites that host them to the Exception Site List.

The exception site list provides users with the option of allowing the same applets that would have been allowed by selecting the Medium option but on a site-by-site basis therefore minimizing the risk of the using more permissive settings.

Java Compiler updated

The javac compiler has been updated to implement definite assignment analysis for blank final field access using "this". See JDK 8 Compatibility Guide for more details.

Change in minimum required Java Version for Java Plugin and Java Webstart

The minimum version of Java required for Java Plugin and Java Webstart is now Java 5. Applets that do not run in Java 5 or later must be ported to a later version of Java to continue to function. Applets written for earlier versions but able to run in at least Java 5 will continue to work.

Change in UsageTracker output formatting

UsageTracker output formatting has been changed to use quoting, to avoid confusion in the log. This may require changes to the way such information is read. The feature can be configured to behave as in previous versions, although the new format is recommended.

See Java Usage Tracker documentation.

Changes to Java Packaging Tools

  • javafxpackager has been renamed to javapackager
  • The "-B" option has been added to the javapackager deploy command to enable you to pass arguments to the bundlers that are used to create self-contained applications. See javapackager (Windows)/(Unix) documentation for information
  • The <fx:bundleArgument> helper parameter argument has been added to JavaFX Ant Task Reference. It enables you to specify an argument (in the <fx:deploy> element) for the bundler that is used to create self-contained applications.

Change in javax.smartcardio.Card.disconnect(boolean reset) method behavior

Prior to the JDK 8u20 and JDK 7u72 releases, the javax.smartcardio.Card.disconnect(boolean reset) method had inverted logic for the 'reset' boolean value passed to it. The card was reset upon a disconnect if false was passed to it and vice versa. Starting with JDK 7u72 and JDK 8u20, the correct behavior as per API documentation has been implemented.

In order to provide backwards compatibility to users who rely on the old behavior, a new system property has been introduced. The following command-line option can be used to enforce the old broken behavior:

-Dsun.security.smartcardio.invertCardReset=true

This property is set by default for 7u72 and later JDK 7 update releases. By default, no behavioral change will be noticed in this area for JDK 7 update releases.

Also the following command-line option can be used to enforce the new correct behavior:

-Dsun.security.smartcardio.invertCardReset=false

This is default for 8u20 and later JDK 8 update releases. In future Java releases, the property will be ignored/disabled and default disconnect method behavior will be as specified by API.

Linux JRE RPM package Name Change

Starting with JDK 8u20, the RPM package name has been changed to include the Java product version.

For example, whereas the rpm name used to be returned simply as "jre", it is now returned as follows:


rpm -qp --qf "%{name}\n" ./jre-8u20-linux-x64.rpm
jre1.8.0_20 

JDK 8 Documentation Updates

New Garbage Collection Tuning Guide added to JDK 8 documentation

The Java HotSpot Virtual Machine Garbage Collection Tuning Guide has been added to the Java SE 8 Developer Guides. This guide describes the garbage collectors included with the Java HotSpot VM and helps you decide which garbage collector can best optimize the performance of your application, especially if it handles large amounts of data (multiple gigabytes), has many threads, and has high transaction rates.

New Deployment Guide

The Java SE Deployment Guide combines information for Java SE and JavaFX deployment into a single guide. This guide provides information about the Java packaging tools, creating self-contained applications, and deploying Java and JavaFX applications that are embedded in a web page or launched from a browser.

Updated Troubleshooting Guide

The Java SE Troubleshooting Guide combines and replaces the Desktop Technologies Troubleshooting Guide and the HotSpot Virtual Machine Troubleshooting Guide, to provide a single location for diagnosing and solving problems that may occur with Java applications created on the Java SE 8 Platform and on Java HotSpot VM. The document introduces the new and improved troubleshooting tools and techniques like Java Mission Control, Java Flight Recordings, and JCMD.

Installation Guide has been updated with changes to Installing With a Configuration File.

Options related to string deduplication have been added to the java command tool page. String deduplication reduces the memory footprint of String objects on the Java heap by taking advantage of the fact that many String objects are identical. Instead of each String object pointing to its own character array, identical String objects can point to and share the same character array. See the option -XX:+UseStringDeduplication for more information.

Bug Fixes

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

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

Area: tools/javac

Synopsis: Implement eager resolution of return types

The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered:

  • The return type needs to be captured
  • The return type needs to have unchecked conversion
  • The return type needs to be unboxed

The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable.

See 8030741.

Area: security-libs/org.ietf.jgss:krb5

Synopsis: sun.security.krb5.KdcComm interprets kdc_timeout as msec instead of sec

An interop issue is found between Java and native Kerberos implementation on BSD (including Apple OS X) regarding the kdc_timeout setting in krb5.conf, which Java interprets as milliseconds and BSD as seconds (when no unit is specified). This release adds support for the "s" (seconds) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about the interop between Java and BSD should use the later format.

See 8044399.

Area: other-libs/corba

Synopsis: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader

The system property org.omg.CORBA.ORBSingletonClass is used to configure the system-wide/singleton ORB. The handling of this system property has changed in 7u55 release to require that the system wide/singleton ORB be visible to the system class loader.

In this release the handling of this system property has been changed to match the behavior found in JDK versions prior to 7u55 release, i.e. the singleton ORB is once again located using the thread context class loader of the first thread to call the no-argument ORB.init method. The change was made to support applications which have been designed to depend on this behavior. Note that this change is applicable to 8u20, 7u65, 6u85 and 5.0u75 releases. For JDK 9, the new behavior where the system wide/singleton ORB needs to be visible to the system class loader, will continue.

See 8042789.

Area: core-libs/java.util.collections

Synopsis: Collection.sort defers now defers to List.sort

Previously Collection.sort copied the elements of the list to sort into an array, sorted that array, then updated list, in place, with those elements in the array, and the default method List.sort deferred to Collection.sort. This was a non-optimal arrangement.

From 8u20 release onwards Collection.sort defers to List.sort. This means, for example, existing code that calls Collection.sort with an instance of ArrayList will now use the optimal sort implemented by ArrayList.

See 8032636.

Area: core-libs/java.net

Synopsis: Digest authentication interop issue

With older versions of Apache Tomcat, certain protocol parameters are expected to be surrounded by double quotes(""). This was the behavior in JDK 7, but was corrected in JDK 8 to be compatible with RFC2617. This caused digest authentication interoperability issues.

Setting the networking property http.auth.digest.quoteParameters to true restores the JDK 7 behavior for compatibility with the older versions of Tomcat.

See 8034170(not public).

Area: tools/javac

Synopsis: javac crashes when mixing lambdas and inner classes

Previously the following sample code was making the compiler fail with a NPE:


class LambdaExpressionWithNonExistentIdCrashesJavacTest {
    void foo() {
        bar(()-> {
            new NonExistentClass(){
                public void any() {}
            };
        });

    }

    void bar(Runnable r) {}
}

where the NonExistentClass was an existing but inaccessible class. Starting with JDK 8u20, javac produces an error message indicating correctly that symbol "NonExistentClass" can't be found.

See 8030816.

Area: tools/javac

Synopsis: ElementType.TYPE_USE is introduced in JDK 8 and should be considered a logical superset of ElementType.TYPE and ElementType.ANNOTATION_TYPE. However, the javac command does not currently recognize ElementType.TYPE_USE as a superset.

javac has been corrected to recognize ElementType.TYPE_USE appropriately.

See 8029017.

Area: tools/javac

Synopsis: javac generates incorrect exception table for multi-catch statements inside a lambda

Handling of try-catch with multiple catches inside a lambda has been corrected.

See 8036942.

Area: core-libs/java.lang.reflect

Synopsis: Default methods affect the result of Class.getMethod and Class.getMethods

Class.getMethod and Class.getMethods were not updated with the 8 release to match the new inheritance definition (both may return non-inherited superinterface methods). Starting with JDK 8u20, the implementation has been changed to match defintion. See JDK 8 Compatibility Guide for more details.

See 8046505.

Known Issues

JDK

Area: install

Synopsis: 64 bit JRE Offline Installer is uncompressed

The 64 bit JRE offline installer for Windows was released as an uncompressed binary in 8u20. In its uncompressed state, the binary is 91.68MB in size.

Only the Windows offline 64 bit JRE bundle is impacted. This does not apply to any other JRE/JDK Windows installers (e.g. 32 bit offline, 32 bit online, or any auto-update bundle, 32 bit or 64 bit).

JavaFX

Area: media

Synopsis: [Linux] JavaFX Media does not run on Ubuntu 14.04

The JavaFX Media component in 8u20 requires the following packages which are not shipped with Ubuntu 14.04:

  • libavcodec53
  • libavformat53
  • libavutil51

Ubuntu 14.04 ships with newer, incompatible versions of these packages.

Workaround: install the specific versions of the required packages.

Area: client-libs

Synopsis: JRE 8u20 crashes while using Japanese IM on Windows

The VM crashes while using Swing controls when some Japanese or Chinese characters are input on Windows platform. There is no workaround.

See 8058858 (not public).

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

The following sections summarize changes made in all Java SE 8u11 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 8u11 b31

Please note that fixes from prior BPR (8u5 b31) are included in this BPR.

Java™ SE Development Kit 8, Update 11 (JDK 8u11)

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

Highlights

This update release contains the following  enhancements and changes:

IANA Data 2014c

JDK 8u11 contains IANA time zone data version 2014c. 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 8u11 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_11
7 1.7.0_65
6 1.6.0_81
5.0 1.5.0_71

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u11) will expire with the release of the next critical patch update scheduled for October 14, 2014.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u11) on November 15, 2014. 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 and Changes

Java Dependency Analysis Tool (jdeps)

A new command-line tool, Java Dependency Analysis Tool (jdeps), is now available that can be used by developers to understand the static dependencies of their applications and libraries. It also provides an -jdkinternals option to find dependencies of any JDK internal APIs that are unsupported and private to JDK implementation.

See jdeps man page and the jdeps Open JDK wiki page.

New Java Control Panel option to disable sponsors

Currently, to disable sponsor offers at the time of installation, the user can deselect the option during installation or can pass SPONSORS=0 as a command line option.

In this release, a new Java Control Panel(JCP) option to disable sponsors is available. To use this option, go to JCP's "Advanced" tab, and check or uncheck "Suppress sponsor offers when updating Java".

This option is applicable to 32 and 64 bit Windows operating systems.

New JAR file attribute - Entry-Point

From this release, a new JAR file attribute, Entry-Point is available. The Entry-Point attribute is used to identify the classes that are allowed to be used as 'entry points' to the RIA. Identifying the entry points helps to prevent unauthorized code from being run when a JAR file has more than one class with a main() method, multiple Applet classes, or multiple JavaFX Application classes. Set this attribute to the fully qualified class name that can be used as the entry point for the RIA. To specify more than one class, separate the classes by a space, for example: Entry-Point: apps.test.TestUI apps.test.TestCLI

If the JAR manifest is signed and the main-class or applet-class entry point specified in the JNLP file or application descriptor differs from the class specified for the Entry-Point attribute, then the RIA is blocked. If the Entry-Point attribute is not present, any class with a main() method, or any Applet or JavaFX Application class in the JAR file can be used to start the RIA.

New JAXP processing limit property - maxElementDepth

A new property, maxElementDepth, is added to provide applications the ability to set limit on maximum element depth in an xml file that they parse. This may be helpful for applications that may use too much resources when processing an xml file with excessive element depth.

  • Name: http://java.sun.com/xml/jaxp/properties/maxElementDepth
  • Definition: Limit the maximum element depth
  • Value: A positive integer. 0 is treated as no limit. Negative numbers are treated as 0.
  • Defaule value: 0
  • System property: jdk.xml.maxElementDepth

See 8031541 (not public).

Bug Fixes

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

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

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

Area: client-libs/AWT

Synopsis: Using RMI from a restricted environment may cause a NullPointerException.

If an application uses RMI and runs in a restricted environment (ie. Java Plugin, Java Web Start), it may not work. In particular, if you run a UI from an RMI callback, a NullPointerException is likely to be thrown.

See 8019274.

Known Issues

Area: xml/jax-ws

Synopsis: JAF initialization in SAAJ clashing with the one in javax.mail

After initialization of SAAJ components, the javax.mail library may fail to work under certain circumstances, which in turn could break the javax.mail's JAF setup.

A possible workaround is to re-add the javax.mail handler before using javax.mail API:


    MailcapCommandMap mailMap = (MailcapCommandMap) 
    CommandMap.getDefaultCommandMap();
    mailMap.addMailcap("multipart/mixed;;x-java-content-
    handler=com.sun.mail.handlers.multipart_mixed");

See 8043129.

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

The following sections summarize changes made in all Java SE 8u5 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 8u5 b31

Bug Fixes

BugId Category Subcategory Description
8028192
(Confidential)
security-libs java.net.ssl PKCS11 is not working correctly.
8038202
(Confidential)
deploy plugin Inconsistent behavior on systems using Deployment Rule Set

Java™ SE Development Kit 8, Update 5 (JDK 8u5)

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

Highlights

This update release contains enhancements and changes including the following:

Olson Data 2013i

JDK 8u5 contains Olson time zone data version 2013i. 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 8u5 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
8 1.8.0_5
7 1.7.0_55
6 1.6.0_75
5.0 1.5.0_65

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

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 8u5) will expire with the release of the next critical patch update scheduled for July 15, 2014.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u5) on August 15, 2014. 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 and Changes

The frequency of some security dialogs has been reduced on systems that run the same RIA multiple times.

See 8029649.

Using "*" in Caller-Allowable-Codebase Attribute.

If a stand-alone asterisk (*) is specified as the value for the Caller-Allowable-Codebase attribute, then calls from JavaScript code to RIA will show a security warning, and users have the choice to allow the call or block the call.

For more information, see JAR File Manifest Attributes for Security documentation.

See 8033707.

Bug Fixes

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

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

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

Area: deploy/plugin
Synopsis: java plugin compatibility with windows 8.1 / IE 11 enhanced protected mode

Starting in this release Java Plug-in is compatible with Windows Enhanced Protected Mode (EPM) on Windows 8.1 and IE 11. You should no longer see any warning related to EPM when trying to run an applet in Internet Explorer (IE). There is a special case for 64-bit Windows - EPM requires both 32-bit and 64-bit Plug-in installed. Please make sure you have both 32-bit and 64-bit JRE installed, otherwise there will be a warning from IE, but Java Plug-in will still run under EPM.

See JDK-8024903 (not public).

Area: other-libs/corba
Synopsis: Enhanced CORBA initializations

The system property org.omg.CORBA.ORBSingletonClass is used to configure the system-wide/singleton ORB. The handling of this system property has changed to require that the system wide/singleton ORB be visible to the system class loader. This is a change from previous releases where the singleton ORB was located using the thread context class loader of the first thread to call the no-argument ORB.init method. The implication of this change is that the system-wide/singleton ORB needs to be deployed on the class path or in the extension directory.

Applications that bundle their own ORB and only configure the property org.omg.CORBA.ORBClass should not be impacted by this change. The per-application ORB will be located via the thread context class loader of the thread calling the 2-argument ORB.init method as before.

See 8025005 (not public).

Area: xml/jaxp
Synopsis: Custom entities mapping files are no longer loaded with full permission

Legacy code may use the JDK internal API SerializerFactory to create a Serializer. In the process, a custom entity mapping file may be specified through the format parameter. The custom file was then loaded with full permission. As of this release, files that complies with java.util.ResourceBundle format, that is, with a ".properties" extension, will continue to be loaded with full permission. However, any other custom mapping files will require specific file access permission when the program is running with a SecurityManager.

The workaround to any issues caused by lack of permission to using an arbitrary file as the entity mapping file is, either changing the file to a resource bundle, or granting file read permission.

See 8029282 (not public).

Known Issues

Area: Install
Synopsis: Patching of JDK8 SUNWj8* Packages is not Supported on Solaris:

In order to update SunWj8* Solaris pkgs consecutively for JDK 8 family releases, JDK 8u5 must be installed as a base package. For example, SUNWj8* pkgs cannot be patched for JDK 8 to JDK 8u5 updates. Full packages must be downloaded and installed.

The following packages cannot be patched directly from the JDK8 release:

SUNWj8cfg, SUNWj8dev, SUNWj8dmo, SUNWj8jmp, SUNWj8man, SUNWj8rt

Patching support of the above packages will resume in JDK 8u5 and later releases of Java.

JDK 8 Release Notes

The Java Platform, Standard Edition 8 Development Kit (JDK 8) is a feature release of the Java SE platform. It contains new features and enhancements in many functional areas.

See the following links to release information about enhancements, changes, bugs, installation, runtime deployment, and documentation. Release Notes files are located on our website only and are not in the documentation download bundle, unless otherwise noted.

JRE Expiration Date

The expiration date for JRE 8 is 05/15/2014. After this date, Java will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.