No results found

Your search did not match any results.

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

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

 

Trending Questions

Release Notes for JDK 9 and JDK 9 Update Releases

Cumulative Release Notes for JDK 9 and JDK 9 Update Releases

Java™ SE Development Kit 9.0.4 (JDK 9.0.4)

January 16, 2018

The full version string for this update release is 9.0.4+11 (where "+" means "build"). The version number is 9.0.4.

For the January CPU, two different JDK9 bundles have been released:

  • Oracle JDK 9.0.4 (contains non-public commercial features, deploy, installers, etc.)
  • OpenJDK 9.0.4 (built only from OpenJDK source code)

This page provides release notes for both bundles. Content that only applies to a specific bundle is presented in sections that contain either OpenJDK or Oracle JDK in their titles. Changes that apply to both bundles are presented in sections that do not have OpenJDK or Oracle JDK in their titles.

NOTE: This is the final planned release for JDK 9.

Users of JDK 9 should update to JDK 10 between its release in March 2018 and the next planned Critical Update Release in April 2018.

IANA Data 2017c

JDK 9.0.4 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 9.0.4 are specified in the following table:

JRE Family Version JRE Security Baseline(Full Version String)
9 9.0.4+11
8 1.8.0_161-b12
7 1.7.0_171-b11
6 1.6.0_181-b10

JRE Expiration Date for Oracle JDK

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 9.0.4) 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 9.0.4) 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 in OpenJDK 9

security-libs/java.security
 Open source the root certificates in Oracle's Java SE Root CA program 

The OpenJDK 9 binary for Linux x64 contains an empty cacerts keystore. This prevents TLS connections from being established because there are no Trusted Root Certificate Authorities installed. As a workaround for OpenJDK 9 binaries, users had to set the javax.net.ssl.trustStore System Property to use a different keystore.

"JEP 319: Root Certificates" [1] addresses this problem by populating the cacerts keystore with a set of root certificates issued by the CAs of Oracle's Java SE Root CA Program. As a prerequisite, each CA must sign the Oracle Contributor Agreement (OCA) http://www.oracle.com/technetwork/community/oca-486395.html, or an equivalent agreement, to grant Oracle the right to open-source their certificates.

[1] JDK-8191486

See JDK-8189131

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.net.ssl
 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS

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

See JDK-8140436

other-libs/corba
 Add additional IDL stub type checks to org.omg.CORBA.ORBstring_to_object method

Applications that either explicitly or implicitly call org.omg.CORBA.ORB.string_to_object, and wish to ensure the integrity of the IDL stub type involved in the ORB::string_to_object call flow, should specify additional IDL stub type checking. This is an "opt in" feature and is not enabled by default.

To take advantage of the additional type checking, the list of valid IDL interface class names of IDL stub classes is configured by one of the following:

  • Specifying the security property com.sun.CORBA.ORBIorTypeCheckRegistryFilter located in the file conf/security/java.security in Java SE 9 or in jre/lib/security/java.security in Java SE 8 and earlier.

  • Specifying the system property com.sun.CORBA.ORBIorTypeCheckRegistryFilter with the list of classes. If the system property is set, its value overrides the corresponding property defined in the java.security configuration.

If the com.sun.CORBA.ORBIorTypeCheckRegistryFilter property is not set, the type checking is only performed against a set of class names of the IDL interface types corresponding to the built-in IDL stub classes.

JDK-8160104 (not public)

Changes

security-libs/javax.crypto
 RSA public key validation 

In 9.0.4, 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.crypto
 Provider default key size is updated 

This change updates the JDK providers to use 2048 bits as the default key size for DSA instead of 1024 bits when applications have not explicitly initialized the java.security.KeyPairGenerator and java.security.AlgorithmParameterGenerator objects with a key size.

If compatibility issues arise, existing applications can set the system property jdk.security.defaultKeySize introduced in JDK-8181048 with the algorithm and its desired default key size.

JDK-8178466 (not public)

security-libs/javax.crypto
 Stricter key generation 

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

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

  • KeyAgreement ka = KeyAgreement.getInstance("DiffieHellman");
  • ka.init(...);
  • ka.doPhase(...);
  • SecretKey sk = ka.generateSecret("AES");

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

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

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

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

B) Implement the following simple key derivation function:

  • 1) Call KeyAgreement.generateSecret() to get the shared secret as a byte array
  • 2) Hash the byte array produced in step 1 using SHA-256
  • 3) Pass the byte array produced in step 2 into the constructor of SecretKeySpec. This constructor also requires the standard name of the secret-key algorithm (e.g. "AES")

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

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

JDK-8185292 (not public)

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

core-svc/javax.management
 JMX Connections need deserialization filters 

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

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

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

JDK-8159377 (not public)

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

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

  1. Support through the API

    The overrideDefaultParser property is supported by the following APIs:

    1. TransformerFactory::setFeature
    2. SchemaFactory::setFeature
    3. Validator::setFeature
    4. XPathFactory::setFeature
  2. Support as a System property
  3. The overrideDefaultParser property can be set through the System.setProperty.

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

  6. Scope and order
  7. 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

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

deploy/webstart
 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.

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

Java™ SE Development Kit 9.0.1 (JDK 9.0.1)

October 17, 2017

The full version string for this update release is 9.0.1+11 (where "+" means "build"). The version number is 9.0.1.

IANA Data 2017b

JDK 9.0.1 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 9.0.1 are specified in the following table:

JRE Family Version JRE Security Baseline(Full Version String)
9 9.0.1+11
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 9.0.1) 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 9.0.1) 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.

Notes

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)

Known Issues

security-libs/java.security
 TLS does not work by default on OpenJDK 9 

The OpenJDK 9 binary for Linux x64 contains an empty cacerts keystore. This prevents TLS connections from being established because there are no Trusted Root Certificate Authorities installed. You may see an exception like the following:


												javax.net.ssl.SSLException: java.lang.RuntimeException:
Unexpected error:
java.security.InvalidAlgorithmParameterException: 
the trustAnchors parameter must be non-empty
											  

As a workaround, users can set the javax.net.ssl.trustStore System Property to use a different keystore. For example, the ca-certificates package on Oracle Linux 7 contains the set of Root CA certificates chosen by the Mozilla Foundation for use with the Internet PKI. This package installs a trust store at /etc/pki/java/cacerts, which can be used by OpenJDK 9.

Only the OpenJDK 64 bit Linux download is impacted. This issue does not apply to any Oracle JRE/JDK download.

Progress on open-sourcing the Oracle JDK Root CAs can be tracked through the issue JDK-8189131.

See JDK-8189131

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)

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

 

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

JDK 9 Documentation

The Java Platform, Standard Edition 9 Development Kit (JDK 9) is a feature release of the Java SE platform. It contains new features and enhancements in many functional areas. You can use the links on this page to open What’s New in JDK 9 as well as the Release Notes documents. The What’s New in JDK 9 document describes important new features in JDK 9. The Release Notes documents describe important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK 9 and Java SE 9. Links to other sources of information about JDK 9 are also provided. The JDK 9 Migration Guide link is provided on this page in the JDK 9 Guides and Reference Documentation group. This document is of particular interest to users moving from previous versions of the JDK. It provides important information about specific compatibility issues as well as new features that you might encounter when moving to JDK 9. Links to the JDK 9 API Specification and the Java Language and Virtual Machine Specifications are provided on this page in the JDK 9 Specifications group.  

Note: The Release Notes files are located only on our website.