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

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

➜ 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

➜ 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

➜ 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

➜ 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

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

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

➜ 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

➜ 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

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

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

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

 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.

 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.

 Additional TeliaSonera Root Certificate

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

 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.

 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.

 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:

 

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

Changes

core-libs/java.util.jar

Bug Fixes

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

  

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

 

Notes

New Features

Certificate Changes

Changes

 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:

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

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

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

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:

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.

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


deploy/webstart

Certificate Changes

New Features

security-libs/java.security

Changes

core-svc/java.lang.management


xml/jax-ws

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:

• New Features and Changes

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

 

---