Java™ SE Development Kit 7, Update 261 (JDK 7u261)

April 14, 2020

The full version string for this update release is 1.7.0_261-b07 (where "b" means "build"). The version number is 7u261.

IANA Data 2019c

JDK 7u261 contains IANA time zone data version 2019c. For more information, refer toTimezone 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 7u261 are specified in the following table:

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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u261) will expire with the release of the next critical patch update scheduled for July 14, 2020.

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

Bug Fixes

This release contains fixes for security vulnerabilities described in theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u261 Bug Fixes page.

Java™ SE Development Kit 7, Update 251 (JDK 7u251)

January 14, 2020

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

IANA Data 2019c

JDK 7u251 contains IANA time zone data version 2019c. For more information, refer toTimezone 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 7u251 are specified in the following table:

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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u251) will expire with the release of the next critical patch update scheduled for April 14, 2020.

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

New Features

Other notes

+ Amazon  + amazonrootca1    DN: CN=Amazon Root CA 1, O=Amazon, C=US  + amazonrootca2    DN: CN=Amazon Root CA 2, O=Amazon, C=US  + amazonrootca3    DN: CN=Amazon Root CA 3, O=Amazon, C=US  + amazonrootca4    DN: CN=Amazon Root CA 4, O=Amazon, C=US

Java SE 7u241 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u241 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u241 b31

Bug Fixes

Java™ SE Development Kit 7, Update 241 (JDK 7u241)

October 15, 2019

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

IANA Data 2019b

JDK 7u241 contains IANA time zone data version 2019b. For more information, refer toTimezone 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 7u241 are specified in the following table:

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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u241) will expire with the release of the next critical patch update scheduled for January 14, 2020.

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

Removed Features and Options

Other notes

java -Djdk.tls.namedGroups="secp256r1, secp384r1,                  secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...

Bug Fixes

This release contains fixes for security vulnerabilities described in theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u241 Bug Fixes page.

Java SE 7u231 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u231 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u231 b32

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

Java™ SE Development Kit 7, Update 231 (JDK 7u231)

July 16, 2019

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

IANA Data 2018i

JDK 7u231 contains IANA time zone data version 2018i. For more information, refer toTimezone 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 7u221 are specified in the following table:

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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u231) will expire with the release of the next critical patch update scheduled for October 15, 2019.

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

New Features

Removed Features and Options

Other notes

Bug Fixes

This release contains fixes for security vulnerabilities described in theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u231 Bug Fixes page.

Java SE 7u221 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u221 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u221 b35

Bug Fixes

Changes in Java SE 7u221 b34

Bug Fixes

Changes in Java SE 7u221 b32

Bug Fixes

Changes in Java SE 7u221 b31

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

Java™ SE Development Kit 7, Update 221 (JDK 7u221)

April 16, 2019

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

IANA Data 2018g

JDK 7u221 contains IANA time zone data version 2018g. For more information, refer toTimezone 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 7u221 are specified in the following table:

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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u221) will expire with the release of the next critical patch update scheduled for July 16, 2019.

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

Issues Fixed

Changes

  new java.util.Calendar.Builder()    .setCalendarType("japanese")    .setFields(Calendar.ERA, 5,        Calendar.YEAR, 1,        Calendar.MONTH, Calendar.MAY,        Calendar.DAY_OF_MONTH, 1)    .build()    .getDisplayName(Calendar.ERA, Calendar.LONG, Locale.US)

Bug Fixes

This release contains fixes for security vulnerabilities described in theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u221 Bug Fixes page.

Java SE 7u211 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u211 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u211 b32

Bug Fixes

Changes in Java SE 7u211 b31

Bug Fixes

Java™ SE Development Kit 7, Update 211 (JDK 7u211)

January 15, 2019

The full version string for this update release is 1.7.0_211-b07 (where "b" means "build"). The version number is 7u211.

IANA Data 2018e

JDK 7u211 contains IANA time zone data version 2018g. For more information, refer toTimezone 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 7u211 are specified in the following table:

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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u211) will expire with the release of the next critical patch update scheduled for April 16, 2019.

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

New Features

Changes

Bug Fixes

This release contains fixes for security vulnerabilities described in theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u211 Bug Fixes page.

Java SE 7u201 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u201 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u201 b31

Bug Fixes

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

October 16, 2018

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

IANA Data 2018e

JDK 7u201 contains IANA time zone data version 2018e. For more information, refer toTimezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u201 are specified in the following table:

JRE 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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u201) will expire with the release of the next critical patch update scheduled for January 15, 2019.

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

Changes

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 theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u201 Bug Fixes page.

Java SE 7u191 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u191 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u191 b32

Bug Fixes

Changes in Java SE 7u191 b31

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

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

July 17, 2018

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

IANA Data 2018e

JDK 7u191 contains IANA time zone data version 2018e. For more information, refer toTimezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u191 are specified in the following table:

JRE 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 onCritical Patch Updates, Security Alerts and Bulletins. This JRE (version 7u191) will expire with the release of the next critical patch update scheduled for October 16, 2018.

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

New Features

Removed Features and Options

Changes

Bug Fixes

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

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

This release also contains fixes for security vulnerabilities described in theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u191 Bug Fixes page.

Java SE 7u181 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u181 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u181 b31

Bug Fixes

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

April 17, 2018

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

IANA Data 2018c

JDK 7u181 contains IANA time zone data version 2018c. For more information, refer toTimezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u181 are specified in the following table:

JRE 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 onCritical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u181) will expire with the release of the next critical patch update scheduled for July 17, 2018.

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

Notes

New Features

Changes

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 theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u181 Bug Fixes page.

Java SE 7u171 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u171 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u171 b31

Bug Fixes

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 toTimezone 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 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 onCritical 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, seeJRE Expiration Date.

New Features

Changes

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

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 theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u171 Bug Fixes page.

Java SE 7u161 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u161 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u161 b33

Bug Fixes

Changes in Java SE 7u161 b32

Bug Fixes

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 toTimezone 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 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 onCritical 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, seeJRE Expiration Date.

Known Issues

Notes

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

New Features

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

Certificate Changes

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

Changes

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

Users wishing to revert to the previous behavior can use the-sigalg option ofkeytool andjarsigner and specify SHA1withDSA and the-keysize option ofkeytool 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 ofkeytool to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:

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

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

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

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

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

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

3. If you use aPKCS11 keystore, the SunPKCS11 provider does not support theSHA256withDSA algorithm.jarsigner and somekeytool commands may fail with the following exception ifPKCS11 is specified with the-storetype option, ex:

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

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

Bug Fixes

This release contains fixes for security vulnerabilities described in theOracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see theJDK 7u161 Bug Fixes page.

Java SE 7u151 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u151 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u151 b33

Bug Fixes

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 toTimezone 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 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 onCritical 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, seeJRE Expiration Date.

Known Issues

Certificate Changes

    ISRG Root X1alias: letsencryptisrgx1DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US

New Features

Changes

Bug Fixes

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

Java SE 7u141 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u141 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u141 b33

Bug Fixes

Changes in Java SE 7u141 b32

Bug Fixes

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 toTimezone 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 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 onCritical 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, seeJRE Expiration Date.

Changes

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 thejava.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 namedtest.jar, use the following command:

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:

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

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap athttp://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.

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

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

Bug Fixes

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

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:

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.

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

Java SE 7u131 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u131 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 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 toTimezone 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 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 onCritical 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, seeJRE Expiration Date.

Notes

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

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

New Features

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.

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.

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 inJEP 290 Serialization Filtering and in <JRE>/lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled.

RMI Registry and Distributed Garbage Collection use the mechanisms ofJEP 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.

In the java.security file, an additional constraint namedjdkCA is added to thejdk.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 thelib/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:

Changes

The performance improvements described inJDK-8130150 andJDK-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

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.

For SSL/TLS/DTLS protocols, the security strength of 3DES cipher suites is not sufficient for persistent connections. By adding3DES_EDE_CBC to thejdk.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.

To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via thejdk.certpath.disabledAlgorithms Security Property) and SSL/TLS connections (via thejdk.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.

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.

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 namedjdk.xml.dsig.SecureValidationPolicy has been added to thejava.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 propertyorg.jcp.xml.dsig.secureValidation to true with thejavax.xml.crypto.XMLCryptoContext.setProperty method, or by running the code with aSecurityManager.

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

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

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.

Seedetails from crypto roadmap for more details.

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.

Class loaders created by thejava.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 thejdk.net.URLClassPath.disableRestrictedPermissions system property.

Bug Fixes

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

Known Issues

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.

Java SE 7u121 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u121 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u121 b32

Bug Fixes

Changes in Java SE 7u121 b31

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

Bug Fixes

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 toTimezone Data Versions in the JRE Software.SeeJDK-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 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 onCritical 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, seeJRE 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 theHow to Implement a Provider in the Java Cryptography Architecture documentation.

Notes

However, on Windows, multiple certificates stored in one keystore are allowed to have non-unique friendly names. The fix forJDK-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)

Changes

The lifecycle management of AWT menu components exposed problems on certain platforms. This fix improves state synchronization between menus and their containers.

In some environments certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, theBasic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by addingBasic to thejdk.http.auth.tunneling.disabledSchemes networking property in thenet.properties file. Now, proxies requiringBasic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removingBasic from thejdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line.

Additionally, thejdk.http.auth.tunneling.disabledSchemes andjdk.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.

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 thejava.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

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 thejarsigner binary that ships with this JDK. Runningjarsigner -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 namedtest.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 updatedjarsigner 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, rerunjarsigner 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 thejdk.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 thezip utility, as follows:

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

Please periodically check theOracle JRE and JDK Cryptographic Roadmap athttp://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, addMD5 to thejdk.jar.disabledAlgorithms security property, ex:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024 and then runjarsigner -verify -J-Djava.security.debug=jar on your JAR files as described above.

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

Known Issues

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.

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.

Bug Fixes

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

Java SE 7u111 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u111 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u111 b32

Bug Fixes

Changes in Java SE 7u111 b31

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

Bug Fixes

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

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 onCritical 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, seeJRE 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
• SeeJDK-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.
• SeeJDK-8154757

• Comodo Root CA removed
• The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file.
• SeeJDK-8141540

• Sonera Class1 CA removed
• The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file.
• SeeJDK-8141276

Enhancements

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"

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.

JDK 7u111 now prints Windows 10 for os.name System property queries running on Windows 10 systems.

Changes

Thejavax.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. Thejavax.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 permissionjava.io.SerializablePermission("enableCustomValueHanlder"). This is used to establish a trust relationship between the users of thejavax.rmi.CORBA.Util andjavax.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 invokingUtil.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 calljavax.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. Thejava.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.

A new-tsadigestalg option is added tojarsigner 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.

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.

The Deployment Toolkit APIinstallLatestJRE() andinstallJRE(requestedVersion) methods fromdeployJava.js and theinstall() method fromdtjava.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.

This enhancement provides a way to specify more granular levels for the GC verification enabled using theVerifyBeforeGC,VerifyAfterGC, andVerifyDuringGC diagnostic options. It introduces a new diagnostic optionVerifySubSet 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, andcodecache_oops.

During the GC verification, only the sub-systems specified usingVerifySubSet 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 withVerifySubSet, 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 oomError occurred during initialization of VMVerifySubSet: 'hello' memory sub-system is unknown, please correct it

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.

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.

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.

Bug Fixes

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

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

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

Java SE 7u101 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u101 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u101 b32

Bug Fixes

Changes in Java SE 7u101 b31

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 toTimezone 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 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 onCritical 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, seeJRE Expiration Date.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, seeOracle Java SE Critical Patch Update Advisory. For a list of bug fixes included in this release, seeJDK 7u101 Bug Fixes page.

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

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

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

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

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.

Because it might cause the browser to hang, we don't process JavaScript-to-Java calls when the Java plugin is launched fromplugin-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 fromplugin-container.exe, do not use JavaScript-To-Java calls that may require more than 11 seconds(the default value ofdom.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 setdom.ipc.plugins.enabled=false. The side effect of this workaround is that it changes the setting for all plugins.

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:

• 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

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

The following sections summarize changes made in all Java SE 7u72 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u99 b31

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 toTimezone 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:

For more information about security baselines, seeDeploying 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 onCritical 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, seeJRE 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, seeOracle Java SE Critical Patch Update Advisory.

Java SE 7u97 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u97 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u97 b33

Bug Fixes

Changes in Java SE 7u97 b32

Bug Fixes

Changes in Java SE 7u97 b31

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 toTimezone 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:

For more information about security baselines, seeDeploying 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 onCritical 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, seeJRE 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 theOracle 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:

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

Java SE 7u95 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u95 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u95 b32

Bug Fixes

Changes in Java SE 7u95 b31

Changes in Java SE 7u95 b13

Bug Fixes

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 toTimezone 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:

For more information about security baselines, seeDeploying 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 onCritical 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, seeJRE Expiration Date.

New Features and Changes

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

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.

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.

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. SeeJSSE User Guide.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, seeOracle Java SE Critical Patch Update Advisory. For a list of bug fixes included in this release, seeJDK 7u95 Bug Fixes page. The following are some of the notable bug fixes included in this release:

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.

After the fix ofJDK-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.

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.

The end times for native TGTs (ticket-granting tickets) are now compared with UTC time stamps.

Java SE 7u91 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u91 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u91 b33

Bug Fixes

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

Changes in Java SE 7u91 b32

Bug Fixes

Changes in Java SE 7u91 b17

Bug Fixes

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 toTimezone 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:

For more information about security baselines, seeDeploying 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 onCritical 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, seeJRE Expiration Date.

Notes

New Features and Changes

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

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 seeThe Java Tutorials, Processing Limits

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

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

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.

Bug Fixes

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

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

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

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

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.

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

Java SE 7u85 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 7u85 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

Changes in Java SE 7u85 b34

Bug Fixes

Changes in Java SE 7u85 b33

Bug Fixes