Java SE 7 Advanced and Java SE 7 Support (formerly known as Java for Business 7)

Release Notes


The Java SE 7 Advanced Platform, available for Java SE Suite, Java SE Advanced, and Java SE Support customers, is based on the current Java SE 7 release.

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

See the following links to release notes including bug fixes, installation information, required licenses, supported configurations, and documentation links contained in this page.

 


Changes in Java SE 7u201 b31

 

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

 

Bug Fixes

BugId Category Subcategory Description
8183504 client-libs javax.swing 8u131 Win 10, issue with wrong position of Sogou IME popup
8176072 client-libs java.awt READING attributes are not available on TSF

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

October 16, 2018

The full version string for this update release is 1.7.0_201-b11 (where "b" means "build"). The version number is 7u201.

IANA Data 2018e

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u201) 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 7u201) on February 15, 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


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.

  

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

  

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

  

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

  

client-libs/java.awt
 Touch Keyboard for Swing/AWT Text Components 

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

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

-Dawt.touchKeyboardAutoShowIsEnabled=false

    

security-libs/javax.crypto
 Improved Cipher Inputs 

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

JDK-8201756 (not public)

Bug Fixes

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

core-libs/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 7u201 Bug Fixes page.

 


Changes in Java SE 7u191 b32

 

Bug Fixes

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

Changes in Java SE 7u191 b31

 

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

 


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

July 17, 2018

The full version string for this update release is 1.7.0_191-b08 (where "b" means "build"). The version number is 7u191.

IANA Data 2018e

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u191) 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 7u191) 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.



New Features

security-libs/javax.net.ssl
 Add support for TLS GCM Cipher Suites 

The following GCM TLS Cipher Suites are now supported:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384



Removed Features and Options

other-libs/javadb
 Removal of Java DB

Java DB, also known as Apache Derby, has been removed in this release.

We recommend that you obtain the latest Apache Derby directly from the Apache project at:

https://db.apache.org/derby

JDK-8197871 (not public)

Changes

core-libs/javax.naming
 Improve LDAP support

Endpoint identification has been enabled on LDAPS connections.

To improve the robustness of LDAPS (secure LDAP over TLS) connections, endpoint identification algorithms have been enabled by default.

Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.

Define this system property (or set it to true) to disable endpoint identification algorithms.

JDK-8200666 (not public)


core-libs/java.io:serialization
 Better stack walking

New access checks have been added during the object creation phase of deserialization. This should not affect ordinary uses of deserialization. However, reflective frameworks that make use of JDK-internal APIs may be impacted. The new checks can be disabled if necessary by setting the system property jdk.disableSerialConstructorChecks to the value "true". This must be done by adding the argument -Djdk.disableSerialConstructorChecks=true to the Java command line.

JDK-8197925 (not public)


Bug Fixes

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

core-libs/javax.naming
 LDAPS Communication Failure

 

Application code using LDAPS with a socket connect timeout that is <= 0 ( the default value ), running on the July CPU 2018 ( 8u181, 7u191, and 6u201 ), may encounter an exception when establishing the connection.

The top most frames from Exception stack traces of applications encountering such issues might resemble the following:

javax.naming.ServiceUnavailableException: <server:port>; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source)
...

 

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

 


Changes in Java SE 7u181 b31

 

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

 

Bug Fixes

BugId Category Subcategory Description
8202263 security-libs java.security keytool exception: Failed to parse input on crt files containing whitespace
8178536 hotspot svc OOM ERRORS + SERVICE-THREAD TAKES A PROCESSOR TO 100%

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

April 17, 2018

The full version string for this update release is 1.7.0_181-b09 (where "b" means "build"). The version number is 7u181.

IANA Data 2018c

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u181) 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 7u181) 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)



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)


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

  

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. The names of JRE and JDK packages now follow jre and jdk patterns respectively, instead of jre and jdk previously used. For example, the new names of JRE and JDK packages are jre1.7 and jdk1.7 respectively.

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

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

  

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

 


Changes in Java SE 7u171 b31

 

Please note that fixes from prior BPR (7u161 b33) are included in this version.

Bug Fixes

BugId Category Subcategory Description
8189789 core-libs java.util.jar tomcat gzip-compressed response bodies appear to be broken in update 151

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

January 16, 2018

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

IANA Data 2017c

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u171) 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 7u171) 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/java.security
 PKCS12 Support for Secret Keys and Trusted Certificates

The PKCS12 KeyStore implementation has been enhanced to support storage of secret keys and trusted certificates. This allows complete migration of existing JKS and JCEKS KeyStores to PKCS12 using the importkeystore option of the keytool utility.



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.



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.



security-libs/java.security
 Support keystore type detection for JKS and PKCS12 keystores

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.



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 the bind address for the default JMX agent. It can be specified via command line while starting the JVM or as part of agent config file (management.properties).
  • Value: IP address of any network interface of the machine


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


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

The java.util.zip.ZipEntry API doc specifies "A directory entry is defined to be one whose name ends with a /". However, in previous JDK releases, java.util.zip.ZipFile.getEntry(String entryName) may return a ZipEntry instance with an entry name that does not end with / for an existing zip directory entry when

  • the passed in argument entryName does not end with a /, and
  • there is a matching zip directory entry with name entryName + / in the zip file.

With this release, the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with / for any zip directory entry.

To revert to the previous behavior, set the system property jdk.util.zip.ensureTrailingSlash to "false".

This change was made in order to fix a regression introduced in JDK 8u141 when verifying signed JARs that has caused some WebStart applications to fail to load.



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.

[1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf
[2] 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. Refer to that file for more information on this property.



security-libs/javax.crypto
 RSA public key validation

In 7u171, 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/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.

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.



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.



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.



security-libs/java.security
 Disable JARs signed with DSA keys less than 1024 bits

DSA keys less than 1024 bits have been added to the jdk.jar.disabledAlgorithms Security property in the java.security file. This property contains a list of disabled algorithms and key sizes for signed JAR files. If a signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:

  1. Applets or Web Start Applications
  2. Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.

Running jarsigner -verify -verbose on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use this command : jarsigner -verify -verbose test.jar

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

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

To address the issue, the JAR file will need to be re-signed with a stronger key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JARs, the existing signature(s) should be removed from the JAR file. This can be done with the zip utility, as follows:

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

Periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.

JDK-8185909 (not public)


xml/jax-ws
 Added wsimport tool command line option -disableXmlSecurity

The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:

  • DOCTYPE declaration is disallowed in documents
  • External general entities are not included by default
  • External parameter entities are not included by default
  • External DTDs are completely ignored

To restore the previous behavior:

  • Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
  • Use the wsimport tool command line option -disableXmlSecurity
JDK-8182873 (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)


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



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:

  • TransformerFactory::setFeature
  • SchemaFactory::setFeature
  • Validator::setFeature
  • XPathFactory::setFeature
  1. Support as a System property

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

  1. Support as a JAXP system property

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

  1. Scope and order

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

JDK-8186080 (not public)


Bug Fixes

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


hotspot/compiler
 Compilers accept modification of final fields outside initializer methods

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

  

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

 


Changes in Java SE 7u161 b33

 

Bug Fixes

BugId Category Subcategory Description
8185346 core-libs java.rmi Relax RMI Registry Serial Filter to allow arrays of any type
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 7u161 b32

 

Bug Fixes

BugId Category Subcategory Description
8190258 core-libs java.time (tz) Support tzdata2017c
8190836 xml jaxb NPE on ExceptionBean when processing SOAP Fault
8180048 hotspot gc Interned string and symbol table leak memory during parallel unlinking

Changes in Java SE 7u161 b31

 

Please note that fixes from prior BPR (7u151 b33) are included in this version.


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

October 17, 2017

The full version string for this update release is 1.7.0_161-b13 (where "b" means "build"). The version number is 7u161.

IANA Data 2017b

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u161) 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 7u161) 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


deploy
 Windows - There is a non-functional Java icon in the control panel after installing 6u171 or 7u161 

Deployment features in 6u171 and 7u161 have been removed. Installing a version of the JRE that has deployment technologies support AFTER having installed the current JRE will cause the Windows Control Panel to display a non-functional Java Control panel icon.

JDK-8185373 (not public)

 


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.



Notes


security-libs/java.security
 Better keystore handling

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

The following procedure can be used to import the keystore:

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

cp /DIR/KEYSTORE /DIR/KEYSTORE.BK

 

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

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

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

3. Import the keystore. For example:

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

 

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

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

 

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

mv /DIR/KEYSTORE.NEW /DIR/KEYSTORE

 

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

JDK-8181370 (not public)


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


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)

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


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

deploy
 JRE 6 and JRE 7 update releases will no longer include deployment technologies

Starting with the Oct 2017 Critical Patch Update, updates for JRE 6 and JRE 7 will no longer include the Java Deployment Technologies required for launching Java applications.

If an application requires a Java SE 6 or 7 JRE, the Java Deployment technology in JRE 8 release can be used to run such applications.

If you need this functionality, please refer to the following deployment invocation methods:

See also: Support Note: the Java SE Deployment Technology Support Lifetime (Doc ID 1640397.1)

JDK-8185747 (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
 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 java.security.interfaces.DSAKeyPairGenerator 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) 
security-libs/java.security
 New defaults for DSA keys in jarsigner and keytool 

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

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

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

1. If you have a script that uses the default key size of keytool to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:

keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...

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

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

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

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

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

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

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

3. If you use a PKCS11 keystore, the SunPKCS11 provider does not support the SHA256withDSA algorithm. jarsigner and some keytool commands may fail with the following exception if PKCS11 is specified with the -storetype option, ex:

keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey

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



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




Changes in Java SE 7u151 b33

 

Bug Fixes


BugId Category Subcategory Description
8184993 security-libs java.security Jar file verification failing with SecurityException: digest missing xxx

Changes in Java SE 7u151 b32

 

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



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

July 18, 2017

The full version string for this update release is 1.7.0_151-b15 (where "b" means "build"). The version number is 7u151.

IANA Data 2017b

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u151) 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 7u151) 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/plugin
JAR file validation changes

Safari browsers, version 10.1 and higher, detect all JDK 7 Java Plug-in software as out-of-date, even if they are above the security baseline. Users can workaround this issue by updating the Java 7 Plug-in settings in the Safari browser's preferences. The setting is accessible by clicking "Security -> Plugin-in Settings..." and unchecking "Enable Security Protection" in the drop list.

JDK-8182641 (not public)


deploy/webstart
Java Plug-in blocked in Safari versions 10.1 and higher

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

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

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


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

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

5. Re-sign the JAR file.

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

 



Certificate Changes


New Let's Encrypt certificates added to root CAs

One new root certificate has been added:

ISRG Root X1
alias: letsencryptisrgx1
DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (not public)


New Features


security-libs/java.security
Disable SHA-1 TLS Server Certificates

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

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

  • jdk.certpath.disabledAlgorithms:

    Three new constraints have been added to this Security Property:

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

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

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

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

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

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

  • jdk.jar.disabledAlgorithms:

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

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

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

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




Changes


core-svc/java.lang.management
JMX Diagnostic improvements

com.sun.management.HotSpotDiagnostic::dumpHeap API is modified to throw an IllegalArgumentException if the supplied file name does not end with “.hprof” suffix. Existing applications that do not provide a file name ending with the “.hprof” extension will fail with an IllegalArgumentException. In that case, applications can either choose to handle the exception or restore old behaviour by setting system property 'jdk.management.heapdump.allowAnyFileSuffix' to true.

JDK-8176055 (not public)


xml/jax-ws
Tighter secure checks on processing WSDL files by wsimport tool

The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:

  • DOCTYPE declaration is disallowed in documents
  • External general entities are not included by default
  • External parameter entities are not included by default
  • External DTDs are completely ignored

To restore the previous behavior:

  • Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
  • Use the wsimport tool command line option –disableXmlSecurity
    NOTE: JDK 7 and JDK 6 support for this option in wsimport will be provided via a Patch release post July CPU
JDK-8182054 (not public)


Bug Fixes


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




Changes in Java SE 7u141 b33

 

Bug Fixes

BugId Category Subcategory Description
8075484 core-libs java.net SocketInputStream.socketRead0 can hang even with soTimeout set

Changes in Java SE 7u141 b32

 

Bug Fixes

BugId Category Subcategory Description
8164002 hotspot compiler Add a new CPU family (S_family) for SPARC S7 and above processors
8165482 hotspot compiler java in ldoms, with cpu-arch=generic has problems
8134119 hotspot compiler Use new API to get cache line sizes
8177817 hotspot runtime Remove assertions in 8u that were removed by 8056124 in 9.
8049717 hotspot runtime expose L1_data_cache_line_size for diagnostic/sanity checks
8043913 hotspot compiler remove legacy code in SPARC's VM_Version::platform_features
8177449 core-libs java.time (tz) Support tzdata2017b
8175251 security-libs java.security Failed to load RSA private key from pkcs12

Changes in Java SE 7u141 b31

 

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


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

The full version string for this update release is 1.7.0_141-b11 (where "b" means "build"). The version number is 7u141.

IANA Data 2017a

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u141) 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 7u141) 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)


Bug Fixes


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

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




Changes in Java SE 7u131 b31

 

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


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

The full version string for this update release is 1.7.0_131-b12 (where "b" means "build"). The version number is 7u131.

IANA Data 2016i

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u131) 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 7u131) 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/java.security
Add support for the SHA224withDSA and SHA256withDSA signature algorithms and DSA keys with sizes up to 2048 bits
Support has been added for the SHA224withDSA and SHA256withDSA signature algorithms and for DSA keys with sizes up to 2048 bits. Previously, only DSA keys with sizes up to 1024 bits were supported.
See JDK-7044060


docs/release_notes
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.io:serialization
Serialization Filter Configuration release note
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-8154961


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 See JDK-8140422



Changes


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

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

See JDK-8154945.



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.



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/javax.net.ssl
Add TLS v1.1 and v1.2 to the client list of default-enabled protocols
TLSv1.2 and TLSv1.1 are now enabled by default on the TLS client end-points. This is similar behavior to what already happens in JDK 8 releases.

See details from crypto roadmap for more details.
See JDK-7093640



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

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




Changes in Java SE 7u121 b32

 

Bug Fixes

BugId Category Subcategory Description
8164410 deploy plugin JRE 6u121 causes applet to fail with: Reset deny session certificate store
8167179 xml jaxp Make XSL generated namespace prefixes local to transformation process

Changes in Java SE 7u121 b31

 

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

Bug Fixes

BugId Category Subcategory Description
8068881 hotspot compiler SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.
8165867 deploy plugin [macos] JVM continuously throw a NullPointerException on new MacOS 10.12
8166875 core-libs java.time (tz) Support tzdata2016g
8063089
(Confidential)
hotspot jfr VM fails to start on Windows with enabled JFR
8166878
(Confidential)
security-libs javax.net.ssl java.net.SocketException: Connection reset (works with 7u80, fails with 7u111)

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

October 18, 2016

The full version string for this update release is 1.7.0_121-b15 (where "b" means "build"). The version number is 7u121.

IANA Data 2016f

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u121) 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 7u121) 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 at a date in the near future. 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)



Notes


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



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 in the net.properties file. 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. The list of disabled algorithms is controlled via a new security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

The following algorithms and key sizes are restricted in this release:

  1. MD2 (in either the digest or signature algorithm)
  2. RSA keys less than 1024 bits 

NOTE: We are planning to restrict MD5-based signatures in signed JARs in the April 2017 CPU.

To check if a weak algorithm or key was used to sign a JAR file, you can use the jarsigner binary that ships with this JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use the following command:
jarsigner -verify -J-Djava.security.debug=jar test.jar

If the file in this example was signed with a weak signature algorithm like MD2withRSA, the following output would be displayed:
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!

The updated jarsigner command will exit with the following warning printed to standard output:
"Signature not parsable or verifiable. The jar will be treated as unsigned. The jar may have been signed with a weak algorithm that is now disabled. For more information, rerun jarsigner with debug enabled (-J-Djava.security.debug=jar)"

To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size.
Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JAR files, the existing signature(s) should be removed from the JAR. This can be done with the zip utility, as follows:

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

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JAR files and other security components. In particular, please note the current plan is to restrict MD5-based signatures in signed JAR files in the April 2017 CPU.

To test if your JARs have been signed with MD5, add MD5 to the jdk.jar.disabledAlgorithms security property, ex:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

and then run jarsigner -verify -J-Djava.security.debug=jar on your JAR files as described above.
JDK-8155973 (not public)



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//compiler
Message "CodeCache is full. Compiler has been disabled"
This message indicates that the CodeCache (a memory area where the JIT compiler keeps the generated compiled code) is full. For that reason, the JIT compiler has been disabled and it won't  compile any more methods and won't generate more compiled code. This can impact the performance of the application.

To avoid this situation, please increase the CodeCache size by using the JVM option, ReservedCodeCacheSize. The default maximum size of the CodeCache on most of the platforms is 48M.
JDK-8163956 (not public)


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




Changes in Java SE 7u111 b32

 

Bug Fixes

BugId Category Subcategory Description
8160664 client-libs 2d JVM crashed with font manager on Solaris 12
8154069 client-libs javax.accessibility Jaws reads wrong values from comboboxes when no element is selected
8161700 deploy webstart Deadlock in Java Web Start application involving JNLPClassLoader
8160275
(Confidential)
deploy deployment_toolkit 7u95 java does not start after the java splash screen in jws application
8156977
(Confidential)
deploy webstart java.lang.NumberFormatException: For input string: 1z

Changes in Java SE 7u111 b31

 

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

Bug Fixes

BugId Category Subcategory Description
8154788
(Confidential)
install install ENT MSI installers should support system account
8036630 hotspot runtime Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array

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

The full version string for this update release is 1.7.0_111-b13 (where "b" means "build"). The version number is 7u111.

IANA Data 2016d

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u111) 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 7u111) 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


Enhancements


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

Users can set this flag in one of two ways:
1. -Djdk.lang.processReaperUseDefaultStackSize=true
2. System.setProperty("jdk.lang.processReaperUseDefaultStackSize", "true")

The problem has been observed only when the 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



core-libs
os.name support for Windows 10
JDK 7u111 now prints Windows 10 for os.name System property queries running on Windows 10 systems.
See JDK-8149143



Changes


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

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

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

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

1. The java.io.SerializablePermission("enableCustomValueHanlder") is not granted by SecurityManager.

2. In the case of applications running on JDK8u and before, the system property "jdk.rmi.CORBA.allowCustomValueHandler" is either not defined or is defined equal to "false" (case insensitive).

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



security-libs/java.security
Support added to jarsigner for specifying timestamp hash algorithm
A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream.
See JDK-8038837



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



deploy
Deployment Tookit API methods no longer install JRE
The Deployment Toolkit API installLatestJRE() and installJRE(requestedVersion) methods from deployJava.js and the install() method from dtjava.js no longer install the JRE. If a user's version of Java is below the security baseline, it redirects the user to java.com to get an updated JRE.
JDK-8148310 (not public)



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



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


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

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

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


Changes in Java SE 7u101 b32

 

Bug Fixes

BugId Category Subcategory Description
8149450 core-libs javax.naming LdapCtx.processReturnCode() throwing Null Pointer Exception
8154304 core-libs javax.naming NullpointerException at LdapReferralException.getReferralContext
8146336 deploy plugin pac file returns wrong proxy with IE only due to broken wildcarding

Changes in Java SE 7u101 b31

 

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

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

The full version string for this update release is 1.7.0_101-b14 (where "b" means "build"). The version number is 7u101.

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

IANA Data 2016a

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u101) 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 7u101) 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 Java SE Critical Patch Update Advisory. For a list of bug fixes included in this release, see JDK 7u101 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)

New JVM Options added: ExitOnOutOfMemory and CrashOnOutOfMemory
Two new JVM flags have been added:

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

New system property to control re-enabling of RC4-based ciphersuites in 7u101, 6u115 releases
Setting -Djdk.tls.enableRC4CipherSuites=true adds the following RC4 based ciphersuites back to the default enabled JSSE ciphersuite list:

  • TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
  • TLS_ECDHE_RSA_WITH_RC4_128_SHA
  • TLS_ECDH_ECDSA_WITH_RC4_128_SHA
  • TLS_ECDH_RSA_WITH_RC4_128_SHA
  • SSL_RSA_WITH_RC4_128_SHA
  • SSL_RSA_WITH_RC4_128_MD5

This system property will only have impact from the JDK 7u101 and JDK 6u115 releases. By default, RC4-based ciphersuites are not in the default enabled list. They were removed in the JDK 6u101 and JDK 7u85 releases.

See JDK-8141050.

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


Changes in Java SE 7u99 b31

 

Please note that fixes from prior BPR (7u97 b33) are included in this version.

Java™ SE Development Kit 7, Update 99 (JDK 7u99)

The full version string for this update release is 1.7.0_99-b04 (where "b" means "build"). The version number is 7u99.

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

IANA Data 2016a

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u99) 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 7u99) 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

The demos, samples, and Documentation bundles for 7u99 are not impacted by the Security Alert for CVE-2016-0636, so version 7u95 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.


Changes in Java SE 7u97 b33

 

Bug Fixes

BugId Category Subcategory Description
8046339 core-libs rmi sun.rmi.transport.DGCAckHandler leaks memory
8130150 hotspot compiler Implement BigInteger.montgomeryMultiply intrinsic
8151522 hotspot compiler Disable 8130150 and 8081778 intrinsics by default

Changes in Java SE 7u97 b32

 

Bug Fixes

BugId Category Subcategory Description
8144593 xml jaxp Suppress not recognized property/feature warning messages from SAXParser

Changes in Java SE 7u97 b31

 

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

Java™ SE Development Kit 7, Update 97 (JDK 7u97)

The full version string for this update release is 1.7.0_97-b02 (where "b" means "build"). The version number is 7u97.

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

IANA Data 2015g

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u97) 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 7u97) 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 7u97 are not impacted by the Security Alert for CVE-2016-0603, so version 7u95 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 7 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

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


All our BPR releases are configured with Java Auto Update disabled as default unless otherwise mentioned.


Changes in Java SE 7u95 b32

 

Bug Fixes

BugId Category Subcategory Description
8144483 hotspot runtime One long Safepoint pause directly after each GC log rotation

Changes in Java SE 7u95 b31

 

Please note that fixes from prior BPR (7u91 b33) are included in this version.

Changes in Java SE 7u95 b13

 

Bug Fixes

BugId Category Subcategory Description
8075773 core-svc tools jps running as root fails after the fix of JDK-8050807
8136759 deploy deployment_toolkit

Regression in Applet startup time with Internet Explorer on 8u60 and 8u65-b14


Java™ SE Development Kit 7, Update 95 (JDK 7u95)

The full version string for this update release is 1.7.0_95-b14 (where "b" means "build"). The version number is 7u95.

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

IANA Data 2015g

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u95) 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 7u95) 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)

jdk.tls.client.protocols system property added to JDK 7
The jdk.tls.client.protocols system property is now available with the release of JDK 7u95. This property was originally introduced in JDK 8 and behaves in the same way. See JSSE User Guide

See JDK-8076369.

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 7u95 Bug Fixes page. The following are some of the notable bug fixes included in this release:

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.

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.

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.

See JDK-8133527.

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.


Changes in Java SE 7u91 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
8133523 deploy plugin _releaseObject called from wrong thread
8076369 security-libs javax.net.ssl Introduce the jdk.tls.client.protocols system property for JDK 7u

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


Changes in Java SE 7u91 b32

 

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

Bug Fixes

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

Changes in Java SE 7u91 b17

 

Bug Fixes

Bug Id Category Subcategory Description
JDK-8075609 client-libs java.awt
java.lang.IllegalArgumentException: a Container is not a focus cycle root of a Component
JDK-8077409 client-libs java.awt Drawing deviates when validate() is invoked on java.awt.ScrollPane
JDK-8076455 client-libs java.awt.i18n IME Composition Window is displayed on incorrect position
JDK-8033069 client-libs javax.swing
mouse wheel scroll closes combobox popup
JDK-8072448 client-libs javax.swing
Can not input Japanese in JTextField on RedHat Linux
JDK-8133321 core-libs  
(tz) Support tzdata2015f
JDK-7119643 core-libs java.io
Not possible to read files with a path longer than 2048 characters
JDK-7150092 core-libs java.net
NTLM authentication fail if user specified a different realm
JDK-8072384 core-libs java.net
Setting IP_TOS on java.net sockets not working on unix
JDK-8080819 core-libs java.net
Inet4AddressImpl regression caused by JDK-7180557
JDK-7044727 core-libs java.util:i18n
(tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
JDK-8072602 core-libs java.util:i18n
Unpredictable timezone on Windows when OS's timezone is not found in tzmappings
JDK-8074350 core-libs java.util:i18n
Support ISO 4217 "Current funds codes" table (A.2)
JDK-7011441 core-libs javax.naming
./jndi/ldap/Connection.java needs to avoid spurious wakeup
JDK-7059542 core-libs javax.naming
JNDI name operations should be locale independent
JDK-8077855 deploy plugin
When applet is relaunched, extra JUT records can be sent
JDK-8133665 deploy plugin
REGRESSION: Hidden applet does not load in 8u60 and 8u65
JDK-8080774 globalization  
DateFormat for Singapore/English locale (en_SG) is M/d/yy instead of d/M/yy
JDK-8056124 core-svc compiler
Hotspot should use PICL interface to get cacheline size on SPARC
JDK-8062591 hotspot compiler
SPARC PICL causes significantly longer startup times
JDK-8078113 hotspot compiler
8011102 changes may cause incorrect results.
JDK-8080012 hotspot compiler
JVM times out with vdbench on SPARC M7-16
JDK-6904403 hotspot jvmti
assert(f == k->has_finalizer(),"inconsistent has_finalizer") with debug VM
JDK-8035150 hotspot jvmti
ShouldNotReachHere() in ConstantPool::copy_entry_to
JDK-7127066 hotspot runtime
Class verifier accepts an invalid class file
JDK-8048353 hotspot runtime
jstack -l crashes VM when a Java mirror for a primitive type is locked
JDK-8072147 hotspot runtime
Preloading libjsig.dylib causes deadlock when signal() is called
JDK-8072863 hotspot runtime
Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath
JDK-8075331 hotspot svc
jdb eval java.util.Arrays.asList(array) shows inconsistent behaviour
JDK-8075410 install install
Registry path for jvm.dll is set to client instead of server
JDK-8050123 other-libs corba
Incorrect property name documented in CORBA InputStream API
JDK-7107611 security-libs java.security
sun.security.pkcs11.SessionManager is scalability blocker
JDK-7190945 security-libs java.security
pkcs11 problem loading NSS libs on Ubuntu
JDK-8062834 security-libs javax.crypto
Allow DHKeyPair generation for bit lengths > 1024 in 6u, 7u
JDK-8059588 security-libs javax.net.ssl
deadlock in java/io/PrintStream when verbose java.security.debug flags are set
JDK-8077102 security-libs org.ietf.igss:krb5
dns_lookup_realm should be false by default
JDK-8077822 tools launcher
javac does not recognize '*.java' as file if '-J' option is specified
JDK-7156085 xml javax.xml.parsers
ArrayIndexOutOfBoundsException throws in UTF8Reader of SAXParser
JDK-8062518 xml jaxp
AIOBE occurs when accessing to document function in extended function in JAXP
JDK-8081392 xml jaxp
getNodeValue should return 'null' value for Element nodes

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

The full version string for this update release is 1.7.0_91-b15 (where "b" means "build"). The version number is 7u91.

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

IANA Data 2015f

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u91) 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 7u91) 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.

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:

xml/jaxp
A new property "maxXMLNameLimit" is added
A new property, maxXMLNameLimit, is added to limit the maximum size of XML names, including element name, attribute name and namespace prefix and URI. It is recommended that users set the limit to the smallest possible number so that malformed XML files can be caught quickly. For more about XML processing limits, please see The Java Tutorials, Processing Limits
JDK-8086733 (not public)


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

See JDK-8080637.

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.

DHKeyPairs with Bit Lengths Greater Than 1024
DHKeyPair generation now supports use of key sizes up to 2048 bits. Key size must be multiples of 64 if less than 1024 bits, or 2048 bits.

See JDK-8062834.

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

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

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

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.


Changes in Java SE 7u85 b34

 

Bug Fixes

BugId Category Subcategory Description
8075773 core-svc tools jps running as root fails after the fix of JDK-8050807
8133196 core-libs java.net HTTPS hostname invalid issue with InetAddress
8081297
(Confidential)
security-libs javax.net.ssl Unable to process PreMasterSecret Tomcat issue
8132082 security-libs javax.net.ssl Let OracleUcrypto accept RSAPrivateKey
8062834 security-libs javax.crypto Allow DHKeyPair generation for bit lengths > 1024 in 6u, 7u
8006935
(Confidential)
security-libs javax.crypto Need to take care of long secret keys in HMAC/PRF computation

Changes in Java SE 7u85 b33

 

Bug Fixes

BugId Category Subcategory Description
8080012 hotspot compiler JVM times out with vdbench on SPARC M7-16

Changes in Java SE 7u85 b31

 

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

Bug Fixes

BugId Category Subcategory Description
8072384 core-libs java.net Setting IP_TOS on java.net sockets not working on unix

Java™ SE Development Kit 7, Update 85 (JDK 7u85)

The full version string for this update release is 1.7.0_85-b15 (where "b" means "build"). The version number is 7u85.

Highlights

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

IANA Data 2015d

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

JRE Family Version JRE Security Baseline
(Full Version String)
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 7u85) 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 7u85) 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.

JavaFX Release Notes

This JDK release includes JavaFX version 2.2.85.

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



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.



Operating system's restricted environment (Native Sandbox)

JDK 8u51 introduced the following changes to Native Sandbox:

  • Native sandbox is available on Windows platform only.

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

    Native sandbox is disabled by default.

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

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

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

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

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

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

Support stronger strength ephemeral DH keys in the SunJSSE provider

The ephemeral DH key size now defaults to 1024 bits during SSL/TLS handshaking in the SunJSSE provider. A new system property, "jdk.tls.ephemeralDHKeySize", is defined to customize the ephemeral DH key sizes. This can be set to "legacy" if the older JDK behavior (DH keysize of 768 bits) is desired. The DH key size for exportable ciphersuites remains at 512 bits.

JDK-8081080 (not public).

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 7u85 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-8077998 (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-8077996 (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-8077904 (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-8073287 (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-8077887 (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-8074424 (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-8076203 (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-8072959 (not public).

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

RC4 is now considered as a weak cipher. Server 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-8074007 (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-8077110 (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-8067696 (not public).

Known Issues


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.

 

 


Changes in Java SE 7u80 b35

 

Bug Fixes

BugId Category Subcategory Description
8069161 deploy plugin Slow cache performance since JRE deploy plugin
8079223 deploy plugin unnecessary performance degradation caused by fix to JDK-8052111
8056124 hotspot compiler Hotspot should use PICL interface to get cacheline size on SPARC hotspot
8062591 hotspot compiler SPARC PICL causes significantly longer startup times hotspot

Changes in Java SE 7u80 b34

 

Please note that Java Auto Update is enabled in this version.

Changes in Java SE 7u80 b33

 

Please note that fixes from prior BPR (7u76 b38) are included in this version.

Changes in Java SE 7u80

For details, refer to Java SE 7 Update 80 Release Notes.


Changes in Java SE 7u76 b38

 

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

Changes in Java SE 7u76 b37

 

Please note that Java Auto Update is enabled in this version.

Bug Fixes

BugId Category Subcategory Description
7171412 client-libs java.awt awt Choice doesn't fire ItemStateChange when selecting item after select() call
8002045
(Confidential)
client-libs java.awt Auto failed and threw exception:java.lang.UnsatisfiedLinkError: java.awt.Choice.initIDs()V for 8b62.

Changes in Java SE 7u76 b36

 

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

Changes in Java SE 7u76 b35

 

Please note that Java Auto Update is enabled in this version.

Bug Fixes

BugId Category Subcategory Description
8033400
(Confidential)
deploy   DRS: Mechanism for system administrators to overrule the JRE version used to launch an applet
8044043
(Confidential)
deploy   Warn user of invalid elements and attributes in ruleset.xml
8072011
(Confidential)
deploy plugin Backport DRS 'force' feature
8067236 deploy plugin DRS with non-force version run rule can block when it should not.
8071897 deploy webstart JRE 8U25 and 8u31 b32 cannot launch Java Web Start with proxy pac but works fine for 7u67
8067846 core-libs java.net (sctp) InternalError when receiving SendFailedNotification
8067680 core-libs java.net (sctp) Possible race initializing native IDs
8062032
(Confidential)
deploy plugin Client certificate authentication issues with TLS 1.2 and browser keystore

Changes in Java SE 7u76 b34

 

Please note that fixes from prior BPR (7u76 b33) are included in this version.

Changes in Java SE 7u76 b33

 

Please note that Java Auto Update is enabled in this version.

Bug Fixes

BugId Category Subcategory Description
8031471 client-libs java.awt Test closed/java/awt/dnd/FileDialogDropTargetTest/FileDialogDropTargetTest.java fails on Solaris zones virtual hosts
8001579 security-libs java.security Cleanup warnings in security native code
8065082
(Confidential)
deploy plugin 7u72 https fails with CertificateException: Java couldn't trust Server
8044758
(Confidential)
deploy   plugin didn't use proxy to download files in javadl
8025332
(Confidential)
deploy plugin REGRESSION: AUTOVUE applet is not embedded in web page on jdk 8

Changes in Java SE 7u76 b32

 

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

Bug Fixes

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

Changes in Java SE 7u76

For details, refer to Java SE 7 Update 76 Release Notes.


Changes in Java SE 7u72 b33

 

Bug Fixes

BugId Category Subcategory Description
8050838 deploy   JRE Install Error in localized Windows 8.1 after join in AD domain
8048887 client-libs javax.swing SortingFocusTraversalPolicy throws IllegalArgumentException from the sort method
8054841 core-libs java.lang (process) ProcessBuilder leaks native memory

Changes in Java SE 7u72 b32

 

Bug Fixes

BugId Category Subcategory Description
8052691
(Confidential)
deploy plugin Caller_allowable_codebase does not honor checkbox when starting with a "t"
8061643 deploy webstart JavaWS fails with proxy autoconfig due to missing "resolve" permission

Changes in Java SE 7u72 b31

 

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

Changes in Java SE 7u72

For details, refer to Java SE 7 Update 72 Release Notes.


Changes in Java SE 7u67 b34

 

Bug Fixes

BugId Category Subcategory Description
8040617 client-libs 2d [macosx] Large JTable cell results in a OutOfMemoryException
8016545 client-libs java.beans java.beans.XMLEncoder.writeObject output is wrong
8041990 client-libs java.awt [macosx] Language specific keys does not work in applets when opened outside the browser
8031046 security-libs org.ietf.jgss:krb5 Native Windows ccache might still get unsupported ticket
8021804 security-libs java.security Certpath validation fails if validity period of root cert does not include validity period of intermediate cert
8056211
(Confidential)
client-libs java.awt api/java_awt/Event/InputMethodEvent/serial/index.html#Input[serial2002] failure

Changes in Java SE 7u67 b31

 

Please note that fixes from prior BPR (7u65 b33) are included in this version.

Changes in Java SE 7u67

For details, refer to Java SE 7 Update 67 Release Notes.


Changes in Java SE 7u65 b33

 

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

Bug Fixes

BugId Category Subcategory Description
8039396 core-libs java.io.serialization NPE when writing a class descriptor object to a custom ObjectOutputStream

Changes in Java SE 7u65

For details, refer to Java SE 7 Update 65 Release Notes.


Changes in Java SE 7u60 b33

 

Bug Fixes

BugId Category Subcategory Description
8038000
(Confidential)
client-libs 2d java.awt.image.RasterFormatException: Incorrect scanline stride
7185456 core-libs java.lang.reflect (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotationsC
7122142 core-libs java.lang (ann) Race condition between isAnnotationPresent and getAnnotations
8005232 core-libs java.lang (JEP-149) Class Instance size reduction
8028627 security-libs javax.crypto Unsynchronized code path from javax.crypto.Cipher to the WeakHashMap used by JceSecurity to store codebase mappings
8028192 security-libs javax.net.ssl Use of PKCS11-NSS provider in FIPS mode broken

Changes in Java SE 7u60 b32

 

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

Bug Fixes

BugId Category Subcategory Description
8038621 deploy javafx Plugin doesn't work for javafx applets

Changes in Java SE 7u60

For details, refer to Java SE 7 Update 60 Release Notes.


Changes in Java SE 7u55 b35

 

Bug Fixes

BugId Category Subcategory Description
8012026 client-libs java.awt [macosx] Component.getMousePosition() does not work in an applet on MacOS
8032669 client-libs javax.swing Mouse release not being delivered to Swing component in 7u45

Changes in Java SE 7u55 b33

 

Bug Fixes

BugId Category Subcategory Description
6653795 hotspot compiler C2 intrinsic for Unsafe.getAddress performs pointer sign extension on 32-bit systems

Changes in Java SE 7u55 b32

 

Bug Fixes

BugId Category Subcategory Description
8013611 client-libs javax.swing Modal dialog fails to obtain keyboard focus
8032781 deploy deployment_toolkit Run rule not working in case of html applet
8032206 deploy plugin Applet with jnlp.Packenabled=True And jnlp.versionEnabled=True Fails

Changes in Java SE 7u55 b31

 

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

Changes in Java SE 7u55

For details, refer to Java SE 7 Update 55 Release Notes.


Changes in Java SE 7u51 b33

 

Bug Fixes

BugId Category Subcategory Description
8029922 deploy webstart 32-bit only Java Web Start apps fail to run on 32- and 64-bit JRE configs

Changes in Java SE 7u51 b32

 

Bug Fixes

BugId Category Subcategory Description
7111452 deploy webstart A .jnlp file specifying several, large, elements cannot be launched

Changes in Java SE 7u55 b31

 

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

Changes in Java SE 7u51

For details, refer to Java SE 7 Update 51 Release Notes.


Changes in Java SE 7u45 b34

 

Bug Fixes

BugId Category Subcategory Description
8028390 deploy plugin allow insecure properties in jnlp file when main application is covered by a DRS Run rule.

Changes in Java SE 7u45 b33

 

Bug Fixes

BugId Category Subcategory Description
8025981 deploy plugin Multi-JREs/ Latest, secure jre 6 version can not be selected for launching specified jre 6 family version applet

Changes in Java SE 7u45 b32

 

Bug Fixes

BugId Category Subcategory Description
8023310 client-libs java.beans Thread contention in the method Beans.IsDesignTime()

Changes in Java SE 7u45 b31

 

Please note that fixes from prior BPR (7u40 b62) are included in this version.

Changes in Java SE 7u45

For details, refer to Java SE 7 Update 45 Release Notes.


Changes in Java SE 7u40 b62

 

Bug Fixes

BugId Category Subcategory Description
8020943 core-svc java.lang.management Memory leak when GCNotifier uses create_from_platform_dependent_str()

Changes in Java SE 7u40

For details, refer to Java SE 7 Update 40 Release Notes.


Changes in Java SE 7u25 b35

 

Bug Fixes

BugId Category Subcategory Description
8015640 deploy plugin REGRESSION: Security boxes appear 2 times with uppercase jnlp codebase

Changes in Java SE 7u25 b34

 

Bug Fixes

BugId Category Subcategory Description
8010437 hotspot compiler guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset

Changes in Java SE 7u25 b33

 

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

Bug Fixes

BugId Category Subcategory Description
8014611 hotspot runtime reserve_and_align() assumptions are invalid on windows
6725714 hotspot gc par compact - add a table to speed up bitmap searches
6550588 client-lib java.awt java.awt.Desktop cannot open file with Windows UNC filename
8005019 client-lib javax.swing JTable passes row index instead of length when inserts selection interval

Changes in Java SE 7u25

For details, refer to Java SE 7 Update 25 Release Notes.


Changes in Java SE 7u21 b31

 

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

Bug Fixes

BugId Category Subcategory Description
7146246 hotspot gc G1: expose some of the -XX flags that drive which old regions to collect during mixed GCs
7193157 hotspot gc G1: Make some develpflags available in product builds
8001424 hotspot gc G1: Rename certain G1-specific flags
8001425 hotspot gc G1: Change the default values for certain G1 specific flags
7162955 hotspot svc Attach api on Solaris, too many open files
6550588 client-lib java.awt java.awt.Desktop cannot open file with Windows UNC filename
8005019 client-lib javax.swing swing JTable passes row index instead of length when inserts selection interval

Changes in Java SE 7u21

For details, refer to Java SE 7 Update 21 Release Notes.


Changes in Java SE 7u17 b32

 

Bug Fixes

BugId Category Subcategory Description
8007740 deploy deployment_toolkit webstart https offline mode failure

Changes in Java SE 7u17 b31

 

Please note that fixes from prior BPR (7u15 b33) are included in this version.

Changes in Java SE 7u17

For details, refer to Java SE 7 Update 17 Release Notes.


Changes in Java SE 7u15

For details, refer to Java SE 7 Update 15 Release Notes.


Changes in Java SE 7u13

For details, refer to Java SE 7 Update 13 Release Notes.


Changes in Java SE 7u11 b32

 

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

Changes in Java SE 7u11

For details, refer to Java SE 7 Update 11 Release Notes.


Changes in Java SE 7u10 b31

 

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

Changes in Java SE 7u10

For details, refer to Java SE 7 Update 10 Release Notes.


Changes in Java SE 7u9 b32

 

Bug Fixes

BugId Category Subcategory Description
7191616 deploy webstart javaws.exe crashes when starting jnlp file
7193219 client-lib java.awt JComboBox serialization fails in JDK 1.7

Changes in Java SE 7u9 b31

 

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

Changes in Java SE 7u9

For details, refer to Java SE 7 Update 9 Release Notes.


Changes in Java SE 7u7 b32

 

Bug Fixes

BugId Category Subcategory Description
6957028 javawebstart other High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.
getInstance()
7171399 java_deployment security Applet throws AccessControlException sporadically while
reading user.home

 


Changes in Java SE 7u7

For details, refer to Java SE 7 Update 7 Release Notes.


Changes in Java SE 7u6

For details, refer to Java SE 7 Update 6 Release Notes.


Changes in Java SE 7u5

For details, refer to Java SE 7 Update 5 Release Notes.


Changes in Java SE 7u4

For details, refer to Java SE 7 Update 4 Release Notes.

Version Name Changed

The following changes were made to the output of the command java -version to releases starting from 7u4 and BPR releases:

  • The string "rev" was removed from the version name of the BPR (for example, 1.7.0_04-b31).
  • The text "for Business" was removed from the output of the command.

In addition, the string "fb" was removed from the bundle name (the file name of the installer).


Changes in Java SE 7u3

For details, refer to Java SE 7 Update 3 Release Notes.


Changes in Java SE 7u2

For details, refer to Java SE 7 Update 2 Release Notes.


Changes in Java SE 7u1

For details, refer to Java SE 7 Update 1 Release Notes.


Java SE 7

Java SE 7 Release Notes

 


Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve