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.
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.
Consolidated Release Notes for JDK 8 and JDK 8 Update Releases
BPR builds are available only as commercial offerings to Oracle customers. They include fixes critical to customers that could not wait until the next scheduled release. Fixes introduced on BPRs are added to later GA releases.
- JDK 8u311 (GA)
- JDK 8u301 (GA and BPR builds)
- JDK 8u291 (GA and BPR builds)
- JDK 8u281 (GA and BPR builds)
- JDK 8u271 (GA and BPR builds)
- JDK 8u261 (GA and BPR builds)
- JDK 8u251 (GA and BPR builds)
- JDK 8u241 (GA and BPR builds)
- JDK 8u231 (GA and BPR builds)
- JDK 8u221 (GA and BPR builds)
- JDK 8u212 (GA and BPR builds)
- JDK 8u211 (GA)
- JDK 8u202 (GA and BPR builds)
- JDK 8u201 (GA)
- JDK 8u192 (GA and BPR builds)
- JDK 8u191 (GA)
- JDK 8u181 (GA and BPR builds)
- JDK 8u172 (GA and BPR builds)
- JDK 8u171 (GA)
- JDK 8u162 (GA and BPR builds)
- JDK 8u161 (GA)
- JDK 8u152 (GA and BPR builds)
- JDK 8u151 (GA)
- JDK 8u144 (GA and BPR builds)
- JDK 8u141 (GA and BPR builds)
- JDK 8u131 (GA and BPR builds)
- JDK 8u121 (GA and BPR builds)
- JDK 8u112 (GA and BPR builds)
- JDK 8u111 (GA)
- JDK 8u102 (GA and BPR builds)
- JDK 8u101 (GA)
- JDK 8u92 (GA and BPR builds)
- JDK 8u91 (GA)
- JDK 8u77 (GA and BPR builds)
- JDK 8u74 (GA and BPR builds)
- JDK 8u72 (GA and BPR builds)
- JDK 8u73 (GA)
- JDK 8u71 (GA)
- JDK 8u66 (GA and BPR builds)
- JDK 8u65 (GA)
- JDK 8u60 (GA and BPR builds)
- JDK 8u51 (GA and BPR builds)
- JDK 8u45 (GA and BPR builds)
- JDK 8u40 (GA and BPR builds)
- JDK 8u31 (GA and BPR builds)
- JDK 8u25 (GA and BPR builds
- JDK 8u20 (GA and BPR builds)
- JDK 8u11 (GA and BPR builds)
- JDK 8u5 (GA and BPR builds)
- JDK 8 (GA)
Java™ SE Development Kit 8, Update 311 (JDK 8u311)
October 19, 2021
The full version string for this update release is 8u311-b11 (where "b" means "build"). The version number is 8u311.
IANA TZ Data 2021a
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 8u311 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 8u311-b11 |
| 7 | 7u321-b08 |
Keeping the JDK up to Date
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u311) be used after the next critical patch update scheduled for January 18, 2022.
Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u311) on 2022-02-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
New Features
Starting from version 8u311, the Marlin graphics rasterizer and its artifacts will be built and distributed as a part of the JDK/JRE bundles. It is not the default rendering engine, however there is an option to enable it by setting the following system property:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each deserialization stream. The behavior is a strict subset of JEP 415: Context-Specific Deserialization Filters to allow a filter factory to be configured using a property configured on the command line or in the security properties file.
The behavior is opt-in based on the presence of the jdk.serialFilterFactory system property on the command line or the jdk.serialFilterFactory security property. If set, the JVM-wide filter factory selects the filter for each stream when the stream is constructed and when a stream-specific filter is set.
The JVM-wide filter factory is a java.util.function.BinaryOperator<sun.misc.ObjectInputFilter> function invoked when each ObjectInputStream is constructed and when the stream-specific filter is set using sun.misc.ObjectInputFilter.Config.setObjectInputFilter(sun.misc.ObjectInputFilter). The parameters are the current filter and a requested filter and the function returns the filter to be used for the stream. When invoked from the ObjectInputStream constructors, the first parameter is null and the second parameter is the static JVM-wide filter. When invoked from sun.misc.ObjectInputFilter.Config.setObjectInputFilter(sun.misc.ObjectInputFilter), the first parameter is the filter currently set on the stream (which was set in the constructor), and the second parameter is the filter requested.
A typical filter factory should use or merge the static JVM-wide filter with other application and context specific filters and the stream-specific filter, if one is set on the stream. The filter factory implementation can also use any contextual information at its disposal, for example, extracted from the application thread context, or its call stack, to compose and combine a new filter. It is not restricted to only use its two parameters.
Refer to Context-Specific Deserialization Filter and Serialization Filtering Guide for details.
Removed Features and Options
The following root certificate from IdenTrust has been removed from the cacerts keystore:
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
Other Notes
This release doesn't correctly identify Windows 11. The property os.name is set to Windows 10 on Windows 11. In HotSpot error logs, the OS is identified as Windows 10; however, the HotSpot error log does show the Build number. Windows 11 has Build 22000.194 or above.
The default priority order of the cipher suites for TLS 1.0 to TLS 1.3 has been adjusted.
For TLS 1.3, TLS_AES_256_GCM_SHA384 is now preferred over TLS_AES_128_GCM_SHA256.
For TLS 1.0 to TLS 1.2, some of the intermediate suites have been lowered in priority as follows:
- Cipher suites that do not preserve forward secrecy have been moved lower in priority than those that do support forward secrecy.
- Cipher suites that use SHA-1 have been moved lower in priority.
The behavior of HttpURLConnection when using ProxySelector has been modified in this JDK release. HttpURLConnection used to fall back to a direct connection attempt if the configured proxy(s) failed to make a connection. Beginning with this release, the default behavior has been changed to no longer use a direct connection when the first proxy connection attempt fails.
A new system property, sun.net.http.fallbackToDirect, can be set to a value of "true" should an application need to fall back to the old behavior (fall back to a direct connection when the first proxy connection attempt fails).
The scope of the com.sun.jndi.ldap.object.trustSerialData system property has been extended to control the deserialization of java objects from the javaReferenceAddress LDAP attribute. This system property now controls the deserialization of java objects from the javaSerializedData and javaReferenceAddress LDAP attributes.
To prevent deserialization of java objects from these attributes, the system property can be set to false. By default, the deserialization of java objects from javaSerializedData and javaReferenceAddress attributes is allowed.
This release doesn't correctly identify Windows Server. The property os.name is set to Windows 2019 on Windows Server 2022. In HotSpot error logs, the OS is identified as Windows 10.0 for Windows Server releases 2016, 2019, and 2022; however, the HotSpot error log does show the Build number. Windows Server 2016 has Build 14393 or above, Windows Server 2019 has Build 17763 or above, and Windows Server 2022 has Build 20348 or above.
The SunPKCS11 security provider can now be initialized with NSS when FIPS-enabled external modules are configured in the Security Modules Database (NSSDB). Before this change, when such a library was configured for NSS in non-FIPS mode, the SunPKCS11 provider would throw a RuntimeException with the message "FIPS flag set for non-internal module".
This change allows the JDK to work properly with recent NSS releases in GNU/Linux operating systems when the system-wide FIPS policy is turned on.
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 8u311 Bug Fixes page.
Java SE 8u301 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates
The following sections summarize changes made in all Java SE 8u301 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in the previous BPR are also included in the current BPR.
Changes in Java SE 8u301 b34
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-6801613 | client-libs | 2d | Cross-platform pageDialog and printDialog top margin entry broken |
| JDK-8268965 | security-libs | javax.net.ssl | TCP Connection Reset when connecting simple socket to SSL server |
Changes in Java SE 8u301 b33
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8261287 (Confidential) | client-libs | 2d | Ductus renderer does not work properly on aarch64, all graphics primitives appear broken |
| JDK-8271206 (Confidential) | deploy | webstart | Passing system property jnlp.sis.session requires multi-clicks |
| JDK-8271087 (Confidential) | install | install | [macos] postinstall script should provide verbose output |
| JDK-8271854 | core-libs | java.nio | Explicitly reclaim cached thread-local direct buffers at thread exit |
| JDK-8205540 | core-svc | debugger | test/hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails with Debuggee did not exit after 15 |
Changes in Java SE 8u301 b32
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8268213 | xml | jax-ws | Racecondition at ContextClassloaderLocal.java:45 |
Java™ SE Development Kit 8, Update 301 (JDK 8u301)
July 20, 2021
The full version string for this update release is 8u301-b09 (where "b" means "build"). The version number is 8u301.
IANA TZ Data 2021a
JDK 8u301 contains IANA time zone data 2021a.
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 8u301 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 8u301-b09 |
| 7 | 7u311-b07 |
Keeping the JDK up to Date
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u301) be used after the next critical patch update scheduled for October 19, 2021.
Java SE Subscription customers managing JRE updates/installs for large numbers of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u301) on 2021-11-19. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
New Features
The support for the Kerberos MSSFU extensions [1] is now extended to cross-realm environments.
By leveraging the Kerberos cross-realm referrals enhancement introduced in the context of JDK-8215032, the 'S4U2Self' and 'S4U2Proxy' extensions may be used to impersonate user and service principals located on different realms.
New system and security properties have been added to enable users to customize the generation of PKCS #12 keystores. This includes algorithms and parameters for key protection, certificate protection, and MacData. The detailed explanation and possible values for these properties can be found in the "PKCS12 KeyStore properties" section of the java.security file.
Also, support for the following SHA-2 based HmacPBE algorithms has been added to the SunJCE provider: HmacPBESHA224, HmacPBESHA256, HmacPBESHA384, HmacPBESHA512, HmacPBESHA512/224, HmacPBESHA512/256
Removed Features and Options
The following root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore:
+ alias name "thawtepremiumserverca [jdk]"
Distinguished Name: 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
+ alias name "verisignclass2g2ca [jdk]"
Distinguished Name: 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
+ alias name "verisignclass3ca [jdk]"
Distinguished Name: OU=Class 3 Public Primary Certification Authority,
O="VeriSign, Inc.", C=US
+ alias name "verisignclass3g2ca [jdk]"
Distinguished Name: 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
+ alias name "verisigntsaca [jdk]"
Distinguished Name: CN=Thawte Timestamping CA,
OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA
+ alias name "gtecybertrustglobalca [jdk]"
Distinguished Name:CN=GTE CyberTrust Global Root,
OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
The following root certificate has been removed from the cacerts truststore:
+ Telia Company
+ soneraclass2ca
DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Other Notes
The following capabilities have been removed from the list of what OracleJDK/OracleJRE RPMs provide: xml-commons-api, jaxp_parser_impl, and java-fonts. This clean-up of the list resolves existing and potential conflicts with modular RPMs.
There are other rpms providing these capabilities, so there should be no impact on packages that depend on them. Package managers can use other RPMs to satisfy the dependencies provided by the OracleJDK/OracleJRE RPMs before this change.
The default encryption algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
For compatibility, a new system property named keystore.pkcs12.legacy is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.
Certain TLS ALPN values couldn't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 character set which converts characters larger than U+00007F (7-bit ASCII) into multi-byte arrays that may not be expected by a peer.
SunJSSE now encodes/decodes String characters as 8-bit ISO_8859_1/LATIN-1 characters. This means applications that used characters above U+000007F that were previously encoded using UTF-8 may need to either be modified to perform the UTF-8 conversion, or set the Java security property jdk.tls.alpnCharset to "UTF-8" revert the behavior.
See the updated guide at https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/alpn.html for more information.
Client-side FTP support in the Java platform is available through the FTP URL stream protocol handler, henceforth referred to as the FTP Client.
The following system property has been added for validation of server addresses in FTP passive mode.
jdk.net.ftp.trustPasvAddress.
In this release, the FTP Client has been enhanced to reject an address sent by a server, in response to a PASV command from the FTP Client, when that address differs from the address which the FTP Client initially connected.
To revert to the prior behavior, the jdk.net.ftp.trustPasvAddress system property can be set to true. The affect of setting this property is that the FTP Client accepts and uses the address value returned in reply to a PASV command
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 8u301 Bug Fixes page.
Java SE 8u291 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates
The following sections summarize changes made in all Java SE 8u291 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in the previous BPR are also included in the current BPR.
Changes in Java SE 8u291 b35
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8268128 | security-libs | java.security | ProviderConfig deadlock in JDK 8u291 |
Changes in Java SE 8u291 b34
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8259886 | security-libs | javax.net.ssl | Improve SSL session cache performance and scalability |
| JDK-8266943 (Confidential) | install | install | Request to reinstate MacOS JRE pkg.dmg binary bundle |
| JDK-8267429 (Confidential) | infrastructure | release_eng | MacOS JRE pkg.dmg binary bundle reinstated |
Changes in Java SE 8u291 b33
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8258753 | core-libs | javax.naming | StartTlsResponse.close() hangs due to synchronization issues |
| JDK-8263788 | javafx | web | JavaFX application freezes completely after some time when using the WebView |
| JDK-8185854 | javafx | controls | NPE on non-editable ComboBox in TabPane with custom Skin |
| JDK-8260300 | security-libs | javax.net.ssl | Restrict TLS signature schemes in 8u |
Changes in Java SE 8u291 b32
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8239589 | javafx | graphics | JavaFX UI will not repaint after reconnecting via Remote Desktop |
Java™ SE Development Kit 8, Update 291 (JDK 8u291)
April 20, 2021
The full version string for this update release is 1.8.0_291-b10 (where "b" means "build"). The version number is 8u291.
IANA TZ Data 2020e, 2020f, 2021a
JDK 8u291 contains IANA time zone data 2020e, 2020f, 2021a.
- * Volgograd switches to Moscow time on 2020-12-27 at 02:00.
- * South Sudan changes from +03 to +02 on 2021-02-01 at 00:00.
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 8u291 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_291-b10 |
| 7 | 1.7.0_301-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 Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u291) be used after the next critical patch update scheduled for July 20, 2021.
Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u291) on 2021-08-20. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
Other Notes
jdk.jndi.object.factoriesFilter: This system and security property allows a serial filter to be specified that controls the set of object factory classes permitted to instantiate objects from object references returned by naming/directory systems. The factory class named by the reference instance is matched against this filter during remote reference reconstruction. The filter property supports pattern-based filter syntax with the format specified by JEP 290. This property applies both to the JNDI/RMI and the JNDI/LDAP built-in provider implementations. The default value allows any object factory class specified in the reference to recreate the referenced object.
com.sun.jndi.ldap.object.trustSerialData: This system property allows control of the deserialization of java objects from the javaSerializedData LDAP attribute. To prevent deserialization of java objects from the attribute, the system property can be set to false value. By default, deserialization of java objects from the javaSerializedData attribute is allowed.
The following root certificates have been added to the cacerts truststore:
+ HARICA
+ haricarootca2015
DN: CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR
+ haricaeccrootca2015
DN: CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR
If the PATH environment variable contains a record configured by Oracle JDK installers from newer releases, the Oracle JRE installer inserts the path to the directory containing the Java commands (java.exe, javaw.exe, and javaws.exe) in the PATH environment variable after that record. Previously, the Oracle JRE installer ignored changes made to the PATH environment variable by Oracle JDK installers from newer releases and incorrectly updated the value of PATH environment variable. Please see the following CSR for additional technical information: https://bugs.openjdk.java.net/browse/JDK-8259858
TLS 1.0 and 1.1 are versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3).
These versions have now been disabled by default. If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.
TLS 1.0 and 1.1 have been disabled. These protocols are NOT used by Java Plugin applets and Java Web Start applications by default. In case of any issues there is an option to re-enable the protocols via Java Control Panel.
In the java.lang.ProcessBuilder implementation on Windows, the system property jdk.lang.Process.allowAmbiguousCommands=false ensures, for each argument, that double-quotes are properly encoded in the command string passed to Windows CreateProcess. An argument with a final trailing double-quote preceded by a backslash is encoded as a literal double-quote; previously, the argument including the double-quote would be joined with the next argument. An empty argument is encoded as a pair of double-quotes ("") resulting in a zero length string passed for the argument to the process; previously, it was silently ignored. An argument containing double-quotes, other than first and last, is encoded to preserve the double-quotes when passed to the process; previously, the embedded double-quotes would be dropped and not passed to the process. If a security manager is set, such as in WebStart applications, double-quotes are encoded as described. When there is no security manager, there is no change to existing behavior; the jdk.lang.Process.allowAmbiguousCommands property can be set to true: jdk.lang.Process.allowAmbiguousCommands=true or false. If left unset, it is the same as setting it to true.
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 8u291 Bug Fixes page.
Java SE 8u281 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates
The following sections summarize changes made in all Java SE 8u281 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in the previous BPR are also included in the current BPR.
Changes in Java SE 8u281 b35
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8204568 | javafx | controls | Relative CSS-Attributes don't work all time |
| JDK-8262829 | client-libs | 2d | Native crash in Win32PrintServiceLookup.getAllPrinterNames() |
| JDK-8262940 (Confidential) | install | [macOS] Java Webstart protocol schemes not registered by JRE installer on macOS | |
| JDK-8247707 | deploy | plugin | UAC prompt of unknown publisher after upgrading java 8u241 |
| JDK-8263575 (Confidential) | install | install | Conflict between JDK rpms and OL8 Modularity prevents dnf install/updates |
| JDK-8263842 (Confidential) | install | install | Clean up "Provides" tag of OracleJDK/JRE rpms |
Changes in Java SE 8u281 b34
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8261970 | xml | reutilization of org.w3c.dom.ls.LSSerializer,produces unexpected result in 8u271 |
Changes in Java SE 8u281 b33
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8259680 | javafx | scenegraph | Need API to query states of CAPS LOCK and NUM LOCK keys |
| JDK-8258803 | xml | WLS/Tuxedo error in encoding post JDK upgrade | |
| JDK-8261209 | xml | jaxp | isStandalone property: remove dependency on pretty-print |
| JDK-8249867 | xml | jaxp | xml declaration is not followed by a newline |
Changes in Java SE 8u281 b32
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8259048 | core-libs | java.time | (tz) Upgrade time-zone data to tzdata2020f |
| JDK-8259215 | install | install | default java version is not updated for double click jar execution |
Changes in Java SE 8u281 b31
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8256925 (Confidential) | security-libs | java.security | Regression with JDK-8236464 in Oracle 8u271 |
| JDK-8256818 | security-libs | javax.net.ssl | SSLSocket that is never bound or connected leaks socket resources |
| JDK-8257670 | security-libs | javax.net.ssl | sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks |
| JDK-8257884 | security-libs | javax.net.ssl | Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test |
| JDK-8257997 | security-libs | javax.net.ssl | sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884 |
| JDK-8256004 (Confidential) | deploy | plugin | DRS: Can not run applet in DRS with java 6 after 8u261 upgrade |
| JDK-8258373 | client-libs | javax.swing | Update the text handling in the JPasswordField |
| JDK-8253368 | security-libs | javax.net.ssl | TLS connection always receives close_notify exception |
Java™ SE Development Kit 8, Update 281 (JDK 8u281)
January 19, 2021
The full version string for this update release is 1.8.0_281-b09 (where "b" means "build"). The version number is 8u281.
IANA Data 2020d
JDK 8u281 contains IANA time zone data version 2020d. For more information, refer to Timezone Data Versions in the JRE Software.
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u281 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_281-b09 |
| 7 | 1.7.0_291-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 Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u281) be used after the next critical patch update scheduled for April 20, 2021.
Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u281) on May 15, 2021. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
New Features
A new -groupname option has been added to keytool -genkeypair so that a user can specify a named group when generating a key pair. For example, keytool -genkeypair -keyalg EC -groupname secp384r1 will generate an EC key pair by using the secp384r1 curve. Because there might be multiple curves with the same size, using the -groupname option is preferred over the -keysize option.
The Apache Santuario library has been upgraded to version 2.1.4. As a result, a new system property com.sun.org.apache.xml.internal.security.parser.pool-size has been introduced.
This new system property sets the pool size of the internal DocumentBuilder cache used when processing XML Signatures. The function is equivalent to the org.apache.xml.security.parser.pool-size system property used in Apache Santuario and has the same default value of 20.
The "certificate_authorities" extension is an optional extension introduced in TLS 1.3. It is used to indicate the certificate authorities (CAs) that an endpoint supports and should be used by the receiving endpoint to guide certificate selection.
With this JDK release, the "certificate_authorities" extension is supported for TLS 1.3 in both the client and the server sides. This extension is always present for client certificate selection, while it is optional for server certificate selection.
Applications can enable this extension for server certificate selection by setting the jdk.tls.client.enableCAExtension system property to true. The default value of the property is false.
Note that if the client trusts more CAs than the size limit of the extension (less than 2^16 bytes), the extension is not enabled. Also, some server implementations do not allow handshake messages to exceed 2^14 bytes. Consequently, there may be interoperability issues when jdk.tls.client.enableCAExtension is set to true and the client trusts more CAs than the server implementation limit.
Other Notes
Starting from macOS Catalina 10.15, applications do not have access to the Desktop, Documents and Downloads folders. So, if you use JavaControlPanel app to access files at the locations specified above, (such as load certificates from the Downloads folder) you must either move the files to another location or grant the required permissions to the JavaControlPanel app.
The steps to required to grant the permissions to JavaControlPanel are provided below:
1. On your Mac, open the Apple menu, click System Preferences, click Security & Privacy, then click Privacy.
2. Select Full Disk Access and click +.
3. In Applications, navigate to the System Preferences app (Applications > System Preferences), and click Open.
Note: You must grant permissions to the System Preferences app because the JavaControlPanel app is a part of that application on macOS.
The JDK update incorporates tzdata2020d. The main change is
- Palestine ends DST earlier than predicted, on 2020-10-24.
Please refer to https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html for more information.
The JDK update incorporates tzdata2020c. The main change is
- Fiji starts DST later than usual, on 2020-12-20.
Please refer to https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html for more information.
Following the JDK's update to tzdata2020b, the long-obsolete files named pacificnew and systemv have been removed. As a result, the "US/Pacific-New" Zone name declared in the pacificnew data file is no longer available for use.
Information regarding this update can be viewed at https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
Bug Fixes
This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 8u281 Bug Fixes page.
Java SE 8u271 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates
The following sections summarize changes made in all Java SE 8u271 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in the previous BPR are also included in the current BPR.
Changes in Java SE 8u271 b37
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8256818 | security-libs | javax.net.ssl | SSLSocket that is never bound or connected leaks socket resources |
| JDK-8257670 | security-libs | javax.net.ssl | sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks |
| JDK-8257997 | security-libs | javax.net.ssl | sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884 |
| JDK-8255908 | core-libs | ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem | |
| JDK-8250627 | core-libs | Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics | |
| JDK-8256685 | xml | jaxp | Behavior change in XML since jdk1.8.0_271 |
| JDK-8238579 | core-libs | java.net | HttpsURLConnection drops the timeout and hangs forever in read |
| JDK-8254982 | core-libs | java.time | (tz) Upgrade time-zone data to tzdata2020c |
| JDK-8255226 | core-libs | java.time | (tz) Upgrade time-zone data to tzdata2020d |
| JDK-8250984 | hotspot | runtime | Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities |
Changes in Java SE 8u271 b34
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8255559 | security-libs | javax.xml.crypto | Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() |
Changes in Java SE 8u271 b33
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8253502 (Confidential) | hotspot | svc | No certificates in "Request Authentication" dialog after upgrading to 8u261 |
| JDK-8252455 (Confidential) | core-libs | java.net | Performance issue caused by 8232854 |
| JDK-8206925 | security-libs | javax.net.ssl | Support the certificate_authorities extension |
| JDK-8250676 (Confidential) | hotspot | svc | JFR recording MonitorEnter events - Stack trace caching |
Changes in Java SE 8u271 b32
Bug Fixes
| BugId | Category | Subcategory | Description |
|---|---|---|---|
| JDK-8254177 | core-libs | java.time | (tz) Upgrade time-zone data to tzdata2020b. |
Java™ SE Development Kit 8, Update 271 (JDK 8u271)
October 20, 2020
The full version string for this update release is 1.8.0_271-b09 (where "b" means "build"). The version number is 8u271.
IANA Data 2020a
JDK 8u271 contains IANA time zone data version 2020a. For more information, refer to Timezone Data Versions in the JRE Software.
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u271 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_271-b09 |
| 7 | 1.7.0_281-b06 |
Keeping the JDK up to Date
Oracle recommends that the JDK is updated with each Critical Patch Update (CPU). In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u271) be used after the next critical patch update scheduled for January 19, 2021.
Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u271) on February 20, 2021. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
New Features
Weak named curves are disabled by default by adding them to the following disabledAlgorithms security properties: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms, and jdk.jar.disabledAlgorithms. The named curves are listed below.
With 47 weak named curves to be disabled, adding individual named curves to each disabledAlgorithms property would be overwhelming. To relieve this, a new security property, jdk.disabled.namedCurves, is implemented that can list the named curves common to all of the disabledAlgorithms properties. To use the new property in the disabledAlgorithms properties, precede the full property name with the keyword include. Users can still add individual named curves to disabledAlgorithms properties separate from this new property. No other properties can be included in the disabledAlgorithms properties.
To restore the named curves, remove the include jdk.disabled.namedCurves either from specific or from all disabledAlgorithms security properties.
To restore one or more curves, remove the specific named curve(s) from the jdk.disabled.namedCurves property.
Curves that are disabled through jdk.disabled.namedCurves include the following:
secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448
The Kerberos client has been enhanced with the support of principal name canonicalization and cross-realm referrals, as defined by the RFC 6806 protocol extension.
As a result of this new feature, the Kerberos client can take advantage of more dynamic environment configurations and does not necessarily need to know (in advance) how to reach the realm of a target principal (user or service).
Support is enabled by default and 5 is the maximum number of referral hops allowed. To turn it off, set the sun.security.krb5.disableReferrals security or system property to false. To configure a custom maximum number of referral hops, set the sun.security.krb5.maxReferrals security or system property to any positive value.
See further information in JDK-8223172.
A new system property, jdk.tls.maxHandshakeMessageSize, has been added to set the maximum allowed size for the handshake message in TLS/DTLS handshaking. The default value of the system property is 32768 (32 kilobytes).
A new system property, jdk.tls.maxCertificateChainLength, has been added to set the maximum allowed length of the certificate chain in TLS/DTLS handshaking. The default value of the system property is 10.
The keytool and jarsigner tools have been updated to warn users when weak cryptographic algorithms are used in keys, certificates, and signed JARs before they are disabled. The weak algorithms are set in the jdk.security.legacyAlgorithms security property in the java.security configuration file. In this release, the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys.
The 'canonicalize' flag in the krb5.conf file is now supported by the JDK Kerberos implementation. When set to true, RFC 6806 name canonicalization is requested by clients in TGT requests to KDC services (AS protocol). Otherwise, and by default, it is not requested.
The new default behavior is different from JDK 14 and previous releases where name canonicalization was always requested by clients in TGT requests to KDC services (provided that support for RFC 6806 was not explicitly disabled with the sun.security.krb5.disableReferrals system or security properties).
Removed Features and Options
NPAPI is considered to be a vulnerable plugin and has been disabled in many browsers. No browsers currently support Java Plugin, which is NPAPI-based, on Linux, Solaris, and MacOS platforms.
Starting from 8u271, the part of Java Plugin responsible for integration and interaction with a browser (in particular libnpjp2 library) and an associated artifact will not be built and is not part of the JRE distribution on Linux, Solaris, and MacOS platforms.
Other notes
A new environment property,
jdk.jndi.ldap.mechsAllowedToSendCredentials, has been added to
control which LDAP authentication mechanisms are allowed to send
credentials over clear LDAP connections - a connection not secured
with TLS. An encrypted LDAP connection is a connection opened
by using ldaps scheme, or a connection opened by using ldap scheme
and then upgraded to TLS with a STARTTLS extended operation.
The value of the property, which is by default not set, is a comma
separated list of the mechanism names that are permitted to authenticate
over a clear connection. If a value is not specified for the property, then all mechanisms
are allowed. If the specified value is an empty list, then no mechanisms are
allowed (except for none and anonymous). The default value for this property is 'null'
( i.e. System.getProperty("jdk.jndi.ldap.mechsAllowedToSendCredentials") returns 'null'). To explicitly permit all mechanisms to authenticate over a clear connection, the property
value can be set to "all". If a connection is downgraded from
encrypted to clear, then only the mechanisms that are explicitly permitted are allowed.
The property can be supplied to the LDAP context environment map, or set globally as a system property. When both are supplied, the environment map takes precedence.
Note: none and anonymous authentication mechanisms are exempted
from these rules and are always allowed regardless of the property value.
The following root certificates have been added to the cacerts truststore:
+ SSL Corporation
+ sslrootrsaca
DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US
+ sslrootevrsaca
DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US
+ sslrooteccca
DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US
The following root certificate has been added to the cacerts truststore:
+ Entrust
+ entrustrootcag4
DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only",
OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
Communication with the alternatives framework of JDK RPM installer starting from 8u261 has changed. JDK RPM installers of prior versions registered two groups of symbolic links with alternatives framework, java and javac. Some names of links in these groups were duplicated, which resulted in installation failures for some versions of alternatives framework. The JDK RPM installer beginning with 8u261 doesn't register the javac group with alternatives framework. All links unique to the javac group have been moved into the java group, but the set of symbolic links registered by the installer have not changed; only the duplicated links have been dropped.
The implication of this change is that if this version of JDK and 8u251 or older versions of the JDK are installed and the previous version is uninstalled, the symbolic links from the java group that are managed by the alternatives framework will be deleted. To restore deleted links, run the command:
/usr/sbin/alternatives --auto java
Some text in the Installer window is hidden/invisible when using Dark mode on macOS. To workaround this issue, switch to Light mode when running the installer. This issue should be resolved by JDK-8249683.
The deserialization of java.lang.reflect.Proxy objects can be limited by setting the system property jdk.serialProxyInterfaceLimit.
The limit is the maximum number of interfaces allowed per Proxy in the stream.
Setting the limit to zero prevents any Proxies from being deserialized including Annotations, a limit of less than 2 might interfere with RMI operations.
Bug Fixes
This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 8u271 Bug Fixes page.
Java SE 8u261 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates
The following sections summarize changes made in all Java SE 8u261 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.
Changes in Java SE 8u261 b36
Bug Fixes
| 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
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 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
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 January 2021 CPU, JDK 7u291 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
Added support for RSASSA-PSS signature algorithms in JSSE implementation.
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
SSLContextalgorithm 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 the following:
sslSocket.setEnabledProtocols(new String[] { "TLSv1.3", "TLSv1.2"});- Setting up and using a TLSv1.3 based SSLContext :
SSLContext ctx = SSLContext.getInstance("TLSv1.3"); - Using the SSLParameters API:
sslParameters.setProtocols(new String[] {"TLSv1.3", "TLSv1.2"}); - The
jdk.tls.client.protocolssystem 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. - The
https.protocolssystem property can also be used to control the protocols on connection obtained through use of theHttpsURLConnectionclass orURL.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 correspondingclose_notifyalert will be sent when receiving aclose_notifyalert, and the connection will be duplex closed. - The
signature_algorithms_certextension 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.dhKeyExchangeFixsystem 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.
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
Two new system properties have been added to customize the TLS signature schemes in JDK. jdk.tls.client.SignatureSchemes has been added for the TLS client side, and jdk.tls.server.SignatureSchemes has been added for the 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.
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.
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.
Other Notes
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.
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.
Prior to JDK 8u261, the JSSE framework passed an array of Strings of all keytypes in one call to the (delegate) javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket) implementation when client authentication is present in an application. Since JDK 8u261, the internal JDK libraries may call the delegate javax.net.ssl.X509KeyManager.chooseClientAlias method in multiple iterations while performing client authentication. One key type per call. https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/X509KeyManager.html#chooseClientAlias-java.lang.String:A-java.security.Principal:A-java.net.Socket-
If application code implements javax.net.ssl.X509KeyManager, ensure that the code logic in that implementation does not assume that all keytypes are passed in the keyType String array in the first call to chooseClientAlias: String chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket)
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 8u261 release includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). The following are descriptions of "Known Issues" which an application might encounter during a SSL handshake, post upgrade to Oracle JDK/JRE 8u261:
- SSL handshake fails on client side with an exception message "Received fatal alert: handshake_failure"
javax.net.ssl|SEVERE|C8|....|TransportContext.java:319|Fatal (HANDSHAKE_FAILURE): Received fatal
alert: handshake_failure (
"throwable" : {
javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
at sun.security.ssl.Alert.createSSLException(Alert.java:131)
at sun.security.ssl.Alert.createSSLException(Alert.java:117)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:187)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:154)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1198)
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1107)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:400)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:372)
Cause: One possible cause is old server intolerance to FFDHE arguments. As per TLS RFC 7919 on server behavior If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list. If the extension is present with FFDHE groups, none of the client's offered groups are acceptable by the server, and none of the client's proposed non-FFDHE cipher suites are acceptable to the server, the server MUST end the connection with a fatal TLS alert of type insufficient_security(71).
Solution: In Oracle JDK 8u261, Finite Field Diffie-Hellman Ephemeral (FFDHE) is enabled by default. User can disable FFDHE via security property "-Djsse.enableFFDHE=false on the server (See JDK-8252716)
- Post upgrade to 8u261 client application encounters close_notify exception during a ClientHello SSL handshake.
javax.net.ssl.SSLProtocolException: Received close_notify during handshake
at sun.security.ssl.Alert.createSSLException(Unknown Source)
at sun.security.ssl.Alert.createSSLException(Unknown Source)
at sun.security.ssl.TransportContext.fatal(Unknown Source)
at sun.security.ssl.TransportContext.fatal(Unknown Source)
at sun.security.ssl.TransportContext.fatal(Unknown Source)
at sun.security.ssl.Alert$AlertConsumer.consume(Unknown Source)
at sun.security.ssl.TransportContext.dispatch(Unknown Source)
at sun.security.ssl.SSLTransport.decode(Unknown Source)
at sun.security.ssl.SSLSocketImpl.decode(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown
Cause: In case of an SSL abbreviated handshake (session resumption) SSL client is adding extra extensions than the agreed protocol's supported extensions. While it is TLS RFC complaint, some old non-compliant server implementations may reject this ClientHello.
Solution: As a work around specify System property -Djdk.tls.client.protocols=
- On upgrade to 8u261, under certain conditions user application may observe higher CPU utilization and slower response time.
Following method reference count would increase in memory profilers
HashMap$Node[] java.util.HashMap.resize()
void sun.security.ssl.SSLSessionContextImpl.put(SSLSessionImpl)
void sun.security.util.MemoryCache.put(Object, Object)
Object java.util.HashMap.put(Object, Object)
Object java.util.HashMap.putVal(int, Object, Object, boolean, boolean)
HashMap$Node[] java.util.HashMap.resize()
Cause: In 8u261, System Property SSLSessionContext.getSessionCacheSize default value was changed from 0 to 20480 ( see JDK-8210985 ) The change was made since with larger heaps, applications are running into situations where the cache ends up with several million entries at the 24 hour mark, at which time many of them are invalidated at almost the same time, which can result in multi-minute pauses, which are effectively service failures.
Solution: Revert back to JDK 8u251 behaviour by setting System Property "-Djavax.net.ssl.sessionCacheSize=0" (set number of entries in the SSL session cache to infinite)
- TLS connection issues with applications using javax.net.ssl.SSLEngine
Cause: The internal implementation of the SSLEngine and associated classes has been reworked with the introduction of TLS v1.3 support. Buffer usage has been improved in the SSLEngine area.
Solution: If an SSLEngine application encounters issues after upgrading to JDK 8u261 or later, refer to the Java 8 API to ensure application code is correct. In particular, applications using SSLEngine should not just depend on SSLEngineResult.Status.BUFFER_UNDERFLOW or SSLEngineResult.Status.BUFFER_OVERFLOW results in order to flush pending data. Buffers should always be flushed after an SSLEngine wrap operation if such a call produces data (where SSLEngineResult.Status.OK may be returned).
- Post upgrading client machine with 8u261, during a SSL handshake, the "Request Authentication" popup dialog does not display any certificates if user has set deployment System Property deployment.security.clientauth.keystore.auto=false
Cause: If deployment.security.clientauth.keystore.auto=false in the deployment.properties file Java Plugin and Java Web Start show “Request Authentication” dialog regardless the number of available certificates. However due to some modifications introduced by TLS 1.3 framework sometimes the list of available certificates might be empty.
Solution: There are two possible ways to resolve the issue:
-
Set deployment System Property deployment.security.clientauth.keystore.auto=true
-
Upgrade to new version 8u281 of Oracle JDK contained the fix for the issue
(see JDK-8253502 )
- Post upgrade to 8u261, during a SSL handshake, user may observe the following "Warning" message in the log
javax.net.ssl|WARNING|03|Finalizer|2020-08-31 09:42:20.203 EDT|null:-1|SSLSocket duplex close failed (
"throwable" : {
java.net.SocketException: Socket is not connected
at java.net.Socket.shutdownOutput(Unknown Source)
at sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(Unknown Source)
at sun.security.ssl.SSLSocketImpl.duplexCloseOutput(Unknown Source)
at sun.security.ssl.SSLSocketImpl.close(Unknown Source)
at sun.security.ssl.BaseSSLSocketImpl.finalize(Unknown Source)
at java.lang.System$2.invokeFinalize(Unknown Source)
at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
at java.lang.ref.Finalizer.access$100(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)}
Cause: JDK 8u261 introduced a new format for TLS logging. Additional data is now captured per event and logged. Exceptions handled by the JDK TLS library code may print verbose information about the cause of such exceptions when logging is enabled.
Solution: User can safely ignore these Warning messages
- Ensure you 3rd party libraries are fully patched. Examples: Bouncy Castle, Apache, OpenSSL, Jetty
Symptoms: New/Unexpected issues from 3rd party library software being used in conjunction with the JDK.
Cause: The new TLS implementation introduces significant changes to the internal, underlying, design of the JDK TLS security libraries. The new design has exposed some bugs in 3rd party software libraries. For the most part, these issues have already been patched in such 3rd party libraries.
Examples include: Apache http-core Bouncy Castle Jetty
Solution: It's good practice to ensure that 3rd party library products being used in conjunction with the JDK TLS API are patched and up to date.
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.
Communication with the alternatives framework of JDK RPM installer starting from 8u261 has changed. JDK RPM installers of prior versions registered two groups of symbolic links with alternatives framework, java and javac. Some names of links in these groups were duplicated, which resulted in installation failures for some versions of alternatives framework. The JDK RPM installer beginning with 8u261 doesn't register the javac group with alternatives framework. All links unique to the javac group have been moved into the java group, but the set of symbolic links registered by the installer have not changed; only the duplicated links have been dropped.
The implication of this change is that if this version of JDK and 8u251 or older versions of the JDK are installed and the previous version is uninstalled, the symbolic links from the java group that are managed by the alternatives framework will be deleted. To restore deleted links, run the command: /usr/sbin/alternatives --auto java
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()
The default SSL session cache size has been updated to 20480 in this JDK release
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.
When setting a serialization filter by using java.io.ObjectInputStream.setObjectInputFilter the method must be called before reading any objects from the stream. If the methods readObject or readUnshared are called, the setObjectInputFilter method throws IllegalStateException.
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.
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
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
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 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 
 or 
 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 
 or 
.
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:
-
-Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=true -
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 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates
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.
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 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.Remotecan be invoked remotely - Methods declared in interfaces that do not extend
Remotedirectly 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
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 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
- Records
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
- Records TLS handshake activity. The event fields include:
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
- Records details of X.509 Certificates. The event fields include:
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
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)
➜ com.sun.org.apache.xml.internal.security.ignoreLineBreaks System Property
An Apache Santuario libraries upgrade introduces a behavioral change where Base64 encoded XML signatures may result in 
 or 
 being appended 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.
An application may continue working with the encoded output data containing the carriage return character (
 or 
) if the application coding logic allows such output.
The com.sun.org.apache.xml.internal.security.ignoreLineBreaks system property may be set to a value of true if an application is unable to handle encoded output data including the carriage return character (
 or 
).
Additional information can be found at https://issues.apache.org/jira/browse/SANTUARIO-482.
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
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
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.JapaneseEraThe 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
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
-
equifaxsecureca
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
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
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
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
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:
JDK-8197871 (not public)
Changes
core-libs/javax.naming
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
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
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
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
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 MechanismsTwo 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
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
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.ORBIorTypeCheckRegistryFilterlocated in the fileconf/security/java.securityin Java SE 9 or injre/lib/security/java.securityin Java SE 8 and earlier. - Specifying the system property
com.sun.CORBA.ORBIorTypeCheckRegistryFilterwith the list of classes. If the system property is set, its value overrides the corresponding property defined in thejava.securityconfiguration.
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
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
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:
- Call KeyAgreement.generateSecret() to get the shared secret as a byte array
- Hash the byte array produced in step 1 using SHA-256
- Pass the byte array produced in step 2 into the constructor of SecretKeySpec. This constructor also
requires the standard name of the secret-key algorithm (e.g. "AES")
This is a simple key derivation function that may provide adequate security in a typical application. Developers should note that this method provides no protection against the reuse of key agreement output in different contexts, so it is not appropriate for all applications. Also, some additional effort may be required to enforce key size restrictions like the ones in Table 2 of NIST SP 800-57pt1r4[2].
C) Set the jdk.crypto.KeyAgreement.legacyKDF system property to "true". This will restore the previous behavior of this KeyAgreement service. This solution should only be used as a last resort if the application code cannot be modified, or if the application must interoperate with a system that cannot be modified. The "legacy" key derivation function and its security are unspecified.
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
JDK-8185292 (not public)
security-libs/javax.crypto
Unlimited cryptography enabled by default
The JDK uses the Java Cryptography Extension (JCE) Jurisdiction Policy files to configure cryptographic algorithm restrictions. Previously, the Policy files in the JDK placed limits on various algorithms. This release ships with both the limited and unlimited jurisdiction policy files, with unlimited being the default. The behavior can be controlled via the new 'crypto.policy' Security property found in the /lib/java.security file. Please refer to that file for more information on this property.
See JDK-8170157
core-libs/java.rmi
The RMI Registry filter is relaxed to allow binding arrays of any type
The RMI Registry built-in serial filter is modified to check only the array size and not the component type. The maximum array size is increased to 1,000,000. The override filter can be used to decrease the limit. Array sizes greater than the maxarray limit will be rejected and otherwise will be allowed. The java.security file contains more information about the sun.rmi.registry.registryFilter property and it will be updated in the conf/security/java.security configuration file to better describe the default behavior and how to override it.
See JDK-8185346
security-libs/javax.net.ssl
Disable exportable cipher suites
To improve the strength of SSL/TLS connections, exportable cipher suites have been disabled in SSL/TLS connections in the JDK by the jdk.tls.disabledAlgorithms Security Property.
See JDK-8163237
security-libs/java.security
Disable JARs signed with DSA keys less than 1024 bits
DSA keys less than 1024 bits have been added to the jdk.jar.disabledAlgorithms Security property in the java.security file. This property contains a list of disabled algorithms and key sizes for signed JAR files. If a signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:
- Applets or Web Start Applications
- Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR 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.
- Support through the API
The
overrideDefaultParserproperty is supported by the following APIs:- TransformerFactory::setFeature
- SchemaFactory::setFeature
- Validator::setFeature
- XPathFactory::setFeature
- Support as a System property
- Support as a JAXP system property
- Scope and order
The overrideDefaultParser property can be set through the System.setProperty.
The overrideDefaultParser property can be set in the JAXP configuration file jaxp.properties.
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
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
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:
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
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:
- If you have a script that uses the default key size of
keytoolto 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 bitsThe workaround is to remove the
-sigalgoption and use the stronger SHA256withDSA default or, at your own risk, use the-keysizeoption ofkeytoolto specify a smaller key size (1024). - If you use
jarsignerto 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 -verifyon 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=jarto thejarsignercommand line, the cause will be output:jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not availableIf compatibility with earlier releases is important, you can, at your own risk, use the
-sigalgoption ofjarsignerand specify the weaker SHA1withDSA algorithm. - If you use a
PKCS11keystore, the SunPKCS11 provider does not support theSHA256withDSAalgorithm.jarsignerand somekeytoolcommands may fail with the following exception ifPKCS11is specified with the-storetypeoption, ex:keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKeyA similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the
-sigalgoption ofkeytooland 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
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
entryNamedoes 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.
- Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
- Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
- Remove the current signature files ( e.g.: rm -f META-INF/*.SF META-INF/*.RSA META-INF/*.DSA ).
- Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).
- Re-sign the JAR file.
NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.
[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.
- Extract the contents of the signed JAR file (e.g.:
jar xf jar-file). - Modify META-INF/MANIFEST.MF file and add a trailing “
/” to the name of the package ( e.g.: Name:org/apache/xml/resolver/). - Remove the current signature files ( e.g.:
rm -f META-INF/*.SF META-INF/*.RSA META-INF/*.DSA). - Recreate the JAR file ( e,g.:
jar cfm jar-file META-INF/MANIFEST.MF input-file(s)). - Re-sign the JAR file.
NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.
[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:TLSServerfor TLS/SSL server certificate chains,TLSClientfor TLS/SSL client certificate chains, andSignedJARfor certificate chains used with signed JARs. -
-
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.
-
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".
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.disableXmlSecurityto true - Use the wsimport tool command line option
–disableXmlSecurityNOTE: 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
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:
- Applets or Web Start Applications
- Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR.
The list of disabled algorithms is controlled via 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:
- MD2 (in either the digest or signature algorithm)
- RSA keys less than 1024 bits
NOTE: We are planning to restrict MD5-based signatures in signed JARs in the April 2017 CPU.
To check if a weak algorithm or key was used to sign a JAR file, you can use the jarsigner binary that ships with this JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.
For example, to check a JAR file named test.jar, use the following command:
jarsigner -verify -J-Djava.security.debug=jar test.jar
If the file in this example was signed with a weak signature algorithm like MD2withRSA, the following output would be displayed:
jar: beginEntry META-INF/my_sig.RSAjar: processEntry: processing blockjar: processEntry caught: java.security.SignatureException: Signature checkfailed. Disabled algorithm used: MD2withRSAjar: 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:
hotspot/jvm/os/processor/cpu_loados/processor/context_switch_rate
This is due to regression JDK-8063089 that was introduced in 8u111 with the changes for JDK-8162419. The fix for JDK-8063089 could not be included in the 8u111 release. It will be available in the next 8u111 BPR build and in the next public release.
JDK-8063089 (not public)
Bug Fixes
This release contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see the JDK 8u111 Bug Fixes page.
Java SE 8u102 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates
The following sections summarize changes made in all Java SE 8u102 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.
To determine the version of your JDK software, use the following command:
java -version
Changes in Java SE 8u102 b35
Bug Fixes
Changes in Java SE 8u102 b34
Bug Fixes
| 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:
-
-Djdk.lang.processReaperUseDefaultStackSize=true -
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:
- D-TRUST Root Class 3 CA 2 2009
- alias: dtrustclass3ca2
- DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
- D-TRUST Root Class 3 CA 2 EV 2009
- alias: dtrustclass3ca2ev
- DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
See JDK-8153080
New IdenTrust certificates added to root CAs
Three new root certificates have been added:
- IdenTrust Public Sector Root CA 1
- alias: identrustpublicca
- DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
- IdenTrust Commercial Root CA 1
- alias: identrustcommercial
- DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
- IdenTrust DST Root CA X3
- alias: identrustdstx3
- DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
See JDK-8154757
Comodo Root CA removed
The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file.
See JDK-8141540
Sonera Class1 CA removed
The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file.
See JDK-8141276
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:
- The
java.io.SerializablePermission("enableCustomValueHanlder")is not granted by SecurityManager. - In the case of applications running on JDK8u and before, the system property
"jdk.rmi.CORBA.allowCustomValueHandler"is either not defined or is defined equal to "false" (case insensitive).
Please note that the "enableCustomValueHanlder" typo will be corrected in the October 2016 releases. In those and future JDK releases, "enableCustomValueHandler" will be the correct SerializationPermission to use.
JDK-8079718 (not public)
security-libs/java.security
Support added to jarsigner for specifying timestamp hash algorithm
A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream.
See JDK-8038837
security-libs/javax.crypto
MSCAPI KeyStore can handle same-named certificates
Java SE KeyStore does not allow certificates that have the same aliases (http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html).
However, on Windows, multiple certificates stored in one keystore are allowed to have non-unique friendly names. The fix for JDK-6483657 makes it possible to operate on such non-uniquely named certificates through the Java API by artificially making the visible aliases unique.
Please note, this fix does not enable creating same-named certificates with the Java API. It only allows you to deal with same-named certificates that were added to the keystore by 3rd party tools.
It is still recommended that your design not use multiple certificates with the same name. In particular, the following sentence will not be removed from the Java documentation: "In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case."
(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html)
See JDK-6483657
security-libs/java.security
DomainCombiner will no longer consult runtime policy for static ProtectionDomain objects when combining ProtectionDomain objects
Applications which use static ProtectionDomain objects (created using the 2-arg constructor) with an insufficient set of permissions may now get an AccessControlException with this fix. They should either replace the static ProtectionDomain objects with dynamic ones (using the 4-arg constructor) whose permission set will be expanded by the current Policy or construct the static ProtectionDomain object with all the necessary permissions.
JDK-8147771 (not public)
Bug Fixes
This release contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see the JDK 8u101 Bug Fixes page.
Known Issues
deploy
JRE 8u101 is not recognized by Internet Explorer (IE) when using static class ID
When a static class id is used to launch an applet or web start application while using JRE 8u101, users will get an unwanted dialogue box stating that they either use the latest JRE or cancel the launch even though they have installed and are using the latest JRE (JRE 8u101).
This specific case is only applicable on Windows and IE.
We do not recommend using static class id for JRE version selection (since JDK 5u6, Dec 2005) per http://www.oracle.com/java/technologies/javase/family-clsid.html.
To work around this issue, users can do one of the following two things:
- Hit launch with the latest version (8u101) and ignore the warning.
- Install JRE 8u102 instead of JRE 8u101 to avoid this issue.
To address this issue, developers can do one of the following two things:
- Use a dynamic class id instead of static class id.
- Use java_version when using an HTML applet or a JNLP descriptor when using JNLP.
JDK-8147457 (not public)
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 :
- QuoVadis Root CA 1 G3
- alias: quovadisrootca1g3
- DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
- QuoVadis Root CA 2 G3
- alias: quovadisrootca2g3
- DN: CN=QuoVadis Root CA 2 G3
- QuoVadis Root CA 3 G3
- alias: quovadisrootca3g3
- DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
- DigiCert Assured ID Root G2
- alias: digicertassuredidg2
- DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Assured ID Root G3
- alias: digicertassuredidg3
- DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G2
- alias: digicertglobalrootg2
- DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G3
- alias: digicertglobalrootg3
- DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Trusted Root G4
- alias: digicerttrustedrootg4
- DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
See JDK-8145954 and JDK-8145955
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
- Launch Firefox
- Type
about:configin the address bar - 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.
- Right-click anywhere inside the displayed list of preferences. Select New then select Boolean.
- Add property name as
dom.ipc.plugins.java.enabled - Add Preference name as dom.ipc.plugins.java.enabled.
- 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.
- Use a text editor to create a "user.js" file in your Firefox profiles folder
- Add entry:
user_pref("dom.ipc.plugins.java.enabled", false);
Option 3: Update "pref.js" file with preference entry
- Locate the "pref.js" file in the Mozilla profiles folder
- 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 thejava.util.Mapinterface. 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 thejava.util.Listinterface instead. If you need to expose your JavaScript objects so that arrays are exposed as lists and not maps, you can use theJava.asJSONCompatible(obj)function, whereobjis 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.Stringwhen 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.Queueandjava.util.Dequeand 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.
- The
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 theruleset.xmlfile. This element and all its sub elements are ignored. In DRS 1.2, the elements are still functionally ignored. However:
- When parsing the
ruleset.xmlfile, 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).
- When parsing the
- Previous to DRS 1.2,
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.sandboxproperty to true indeployment.propertiesfile.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-Pathmanifest 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:
- Command-line arguments can be passed to self-contained applications. Default arguments are defined when the package is created, which can be overridden by the user when the application is started. See Passing Arguments to a Self-Contained Application.
- File associations can be set up when a self-contained application is installed so that the operating system automatically runs the application for registered file extensions or MIME types. See Associating Files with a Self-Contained Application.
- The
UserJvmOptionsServiceAPI is available for altering JVM options in self-contained applications. The new settings are used the next time the application is started. See Customizing JVM Options in Self-Contained Applications. - Multiple entry points are supported for self-contained applications, which enables a suite of products to be bundled into the same application package. See Supporting Multiple Entry Points.
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.dirsor-Djava.ext.dirssystem property is set to alter the default location; or${java.home}/lib/endorseddirectory exists; or${java.home}/lib/extcontains 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.
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 DifferencesThe 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 UpdatedJava SE tools have been updated. See Tools Enhancements in JDK 8 for details.
Change in default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercentThe 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.
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.
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 SolarisIf 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 JFRThe 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 EnhancementsStarting with JDK 8u40 release, JavaFX controls are enhanced to support assistive technologies, meaning that JavaFX controls are now accessible. In addition, a public API is provided to allow developers to write their own accessible controls.
Accessibility support is provided on Windows and Mac OS X platforms and includes:
- Support for reading JavaFX controls by a screen reader
- JavaFX controls are traversable using the keyboard
- Support for a special high-contrast mode that makes controls more visible to users.
See 8043344 (not public).
JDK 8u40 release includes new JavaFX UI controls; a spinner control, formatted-text support, and a standard set of alert dialogs.
- Spinner Control:
A Spinner is a single line text field that lets the user select a number or an object value from an ordered sequence. See javafx.scene.control.Spinner class for more information.
- Formatted Text:
A new TextFormatter class provides text formatting capablity for subclasses of TextInputControl (for example, TextField and TextArea). See javafx.scene.control.TextFormatter class for more information.
- Dialogs:
The Dialog class allows applications to create their own custom dialogs. In addition, an an Alert class is also provided, that extends Dialog, and provides support for a number of pre-built dialog types that can be easily shown to users to prompt for a response. See javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog, javafx.scene.control.ChoiceDialog classes for more information.
See 8043350 (not public).
Commercial Features
- Application Class Data Sharing (AppCDS):
Application Class Data Sharing (AppCDS) extends CDS (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:+UseAppCDSoption 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.SystemResourcePressureMXBeanshould be registered. The memory pressure is then set using the "MemoryPressure" attribute.A new command line flag
-XX:MemoryRestrictionthat 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/java/technologies/javase-subscription-overview.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
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:
This document contains the following topics:
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. Seejavapackager(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.
- What's New in JDK 8
- Compatibility Guide for JDK 8
- Known Issues for JDK 8
- JDK 8 Adoption Guide
- Java Mission Control 5.3 Release Notes
- Java SE 8 Names and Versions
- JDK 8 and JRE 8 Certified System Configurations
- JDK 8 and JRE 8 Supported Locales
- JDK 8 Installation Guide (All Platfoms)
- JDK 8 Desktop Technologies Troubleshooting Guide (also in docs bundle)
- JDK 8 HotSpot VM Troubleshooting Guide (also in docs bundle)
- Developer Guides and API Documentation (also in docs bundle)
- JDK README
- JRE README
- Submitting a Bug Report and Available Support Options
- Copyright and License Terms for Documentation(also in docs bundle)
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.