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

Release Notes


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

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

Find information about Java SE Support at Oracle Java SE Support.

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

 


Changes in Java SE 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/webstart
JAR file validation changes

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

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

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


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

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

5. Re-sign the JAR file.

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

 



Certificate Changes


New Let's Encrypt certificates added to root CAs

One new root certificate has been added:

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


New Features


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

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

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

  • jdk.certpath.disabledAlgorithms:

    Three new constraints have been added to this Security Property:

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

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

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

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

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

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

  • jdk.jar.disabledAlgorithms:

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

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

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

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




Changes


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

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

JDK-8176055 (not public)


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

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

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

To restore the previous behavior:

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


Bug Fixes


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




Changes in Java SE 7u141 b33

 

Bug Fixes

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

Changes in Java SE 7u141 b32

 

Bug Fixes

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

Changes in Java SE 7u141 b31

 

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


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

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

IANA Data 2017a

JDK 7u141 contains IANA time zone data version 2017a. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_141-b11
6 1.6.0_151-b10

 

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u141) will expire with the release of the next critical patch update scheduled for July 18, 2017.

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



Changes


security-libs/java.security
MD5 added to jdk.jar.disabledAlgorithms Security property
This JDK release introduces a new restriction on how MD5 signed JAR files are verified. If the signed JAR file uses MD5, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:

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

The list of disabled algorithms is controlled via the security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

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

For example, to check a JAR file named test.jar, use the following command:

jarsigner -verify test.jar

If the file in this example was signed with a weak signature algorithm like MD5withRSA, the following output would be displayed:

The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details.

More details can be displayed by using the verbose option:

jarsigner -verify -verbose test.jar

The following output would be displayed:
- Signed by "CN=weak_signer" 
    Digest algorithm: MD5 (weak) 
    Signature algorithm: MD5withRSA (weak), 512-bit key (weak) 
  Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 
    Timestamp digest algorithm: SHA-256 
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key

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

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

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.
JDK-8171121 (not public)

 



core-libs/java.net
New system property to control caching for HTTP SPNEGO connection.
A new JDK implementation specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

When connecting to an HTTP server that uses SPNEGO to negotiate authentication, and when connection and authentication with the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP server using SPNEGO usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol in order to force requesting new authentication with each new request to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP SPNEGO connections. If jdk.spnego.cache is defined and evaluates to false, then all caching will be disabled for HTTP SPNEGO connections. Setting this system property to false may, however, result in undesirable side effects:

  • Performance of HTTP SPNEGO connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
  • Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8170814 (not public)


core-libs/java.net
New system property to control caching for HTTP NTLM connection.
A new JDK implementation specific system property to control caching for HTTP NTLM connection is introduced. Caching for HTTP NTLM connection remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

On some platforms, the HTTP NTLM implementation in the JDK can support transparent authentication, where the system user credentials are used at system level. When transparent authentication is not available or unsuccessful, the JDK only supports getting credentials from a global authenticator. If connection to the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP NTLM server usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP NTLM protocol in order to force requesting new authentication with each new requests to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP NTLM connections. If jdk.ntlm.cache is defined and evaluates to false, then all caching will be disabled for HTTP NTLM connections. Setting this system property to false may, however, result in undesirable side effects:

  • Performance of HTTP NTLM connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
  • Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8163520 (not public)


Bug Fixes


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

security-libs/javax.net.ssl
Correction of IllegalArgumentException from TLS handshake
A recent issue from the JDK-8173783 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.
See JDK-8173783


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




Changes in Java SE 7u131 b31

 

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


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

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

IANA Data 2016i

JDK 7u131 contains IANA time zone data version 2016i. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_131-b12
6 1.6.0_141-b12

 

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u131) will expire with the release of the next critical patch update scheduled for April 18, 2017.

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


Notes


core-libs/javax.naming
Improved protection for JNDI remote class loading
Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set the following system property to the string "true", as appropriate:

    com.sun.jndi.rmi.object.trustURLCodebase
    com.sun.jndi.cosnaming.object.trustURLCodebase
JDK-8158997 (not public)


security-libs/java.security
jarsigner -verbose -verify should print the algorithms used to sign the jar
The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak.

Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property jdk.jar.disabledAlgorithms, it will be labeled with "(weak)".

For example:

- Signed by "CN=weak_signer"
   Digest algorithm: MD2 (weak) 
   Signature algorithm: MD2withRSA (weak), 512-bit key (weak)
 Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
   Timestamp digest algorithm: SHA-256 
   Timestamp signature algorithm: SHA256withRSA, 2048-bit key 
See JDK-8163304

 


New Features

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)



Bug Fixes


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




Changes in Java SE 7u111 b32

 

Bug Fixes

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

Changes in Java SE 7u111 b31

 

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

Bug Fixes

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

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

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

IANA Data 2016d

JDK 7u111 contains IANA time zone data version 2016d. For more information, refer to Timezone Data Versions in the JRE Software.
See JDK-8151876

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_111-b13
6 1.6.0_121-b09

 

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u111) will expire with the release of the next critical patch update scheduled for October 19, 2016.

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

Certificate Changes


New DTrust certificates added to root CAs
Two new root certificates have been added:

D-TRUST Root Class 3 CA 2 2009
alias: dtrustclass3ca2
DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE

D-TRUST Root Class 3 CA 2 EV 2009
alias: dtrustclass3ca2ev
DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
See JDK-8153080

New IdenTrust certificates added to root CAs
Three new root certificates have been added:

IdenTrust Public Sector Root CA 1
alias: identrustpublicca
DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US

IdenTrust Commercial Root CA 1
alias: identrustcommercial
DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US

IdenTrust DST Root CA X3
alias: identrustdstx3
DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
See JDK-8154757

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


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


Enhancements


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

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

The problem has been observed only when the JVM is started from JNI code in which TLS is declared using "__thread"
See JDK-8130425



hotspot/compiler
Implemented performance improvements for BigInteger.montgomeryMultiply
We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture.
See JDK-8130150



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



Changes


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

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

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

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

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

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

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



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



security-libs/javax.net.ssl
Modify requirements on Authority Key Identifier extension field during X509 certificate chain building
The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. See JDK-8072463



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



hotspot/gc
Providing more granular levels for GC verification
This enhancement provides a way to specify more granular levels for the GC verification enabled using the VerifyBeforeGC, VerifyAfterGC, and VerifyDuringGC diagnostic options. It introduces a new diagnostic option VerifySubSet with which one can specify the subset of the memory system that should be verified.

With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap, and codecache_oops.

During the GC verification, only the sub-systems specified using VerifySubSet get verified:

D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test
[0.095s][debug ][gc,verify] Threads
[0.099s][debug ][gc,verify] C-heap
[0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms
[0.120s][debug ][gc,verify] Threads
[0.124s][debug ][gc,verify] C-heap
[0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms
[0.148s][debug ][gc,verify] Threads
[0.152s][debug ][gc,verify] C-heap

If any invalid memory sub-systems are specified with VerifySubSet, the Java process exits with the following error message:

D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom
Error occurred during initialization of VM
VerifySubSet: 'hello' memory sub-system is unknown, please correct it

See JDK-8072725



hotspot/compiler
Removed PICL warning message
In 8u40 and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message:

Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing.
Performance will not be optimal.

This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed.
See JDK-8144957



core-libs/javax.naming
 Improved exception handling for bad LDAP referral replies
The JDK was throwing a NullPointerException when a non-compliant REFERRAL status result was sent but no referral values were included. With this change, a NamingException with message value of "Illegal encoding: referral is empty" will be thrown in such circumstances.
See JDK-8149450



security-libs/java.security
DomainCombiner will no longer consult runtime policy for static ProtectionDomain objects when combining ProtectionDomain objects
Applications which use static ProtectionDomain objects (created using the 2-arg constructor) with an insufficient set of permissions may now get an AccessControlException with this fix. They should either replace the static ProtectionDomain objects with dynamic ones (using the 4-arg constructor) whose permission set will be expanded by the current Policy or construct the static ProtectionDomain object with all the necessary permissions.
JDK-8147771 (not public)



Bug Fixes


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

security-libs/javax.net.ssl
Fix to resolve "Unable to process PreMasterSecret, may be too big" issue
Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95, and JDK 6u111. The main error seen corresponded to an exception like the following:

handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big

See JDK-8149017

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


Changes in Java SE 7u101 b32

 

Bug Fixes

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

Changes in Java SE 7u101 b31

 

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

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

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

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

IANA Data 2016a

JDK 7u101 contains IANA time zone data version 2016a. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_101
6 1.6.0_115

 

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u101) will expire with the release of the next critical patch update scheduled for July 19, 2016.

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

Bug Fixes

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

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

Regression in Applet startup time fixed
JDK-8080977 introduced delay on applet launch. The delay appears only on IE and lasts about 20 seconds. JDK-8136759 removed this delay.

See JDK-8136759

DSA signature generation is now subject to a key strength check
For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (e.g. using (2048, 256)-bit DSA keys with SHA1withDSA signature), the operation will fail with the error message:

"The security strength of SHA1 digest algorithm is not sufficient for this key size."

JDK-8138593 (not public)

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

  • ExitOnOutOfMemory - When you enable this option, the JVM exits on the first occurrence of an out-of-memory error. It can be used if you prefer restarting an instance of the JVM rather than handling out of memory errors.

  • CrashOnOutOfMemoryError - If this option is enabled, when an out-of-memory error occurs, the JVM crashes and produces text and binary crash files (if core files are enabled).

See JDK-8138745.

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

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

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

See JDK-8141050.

Firefox 42 liveconnect problem
Because it might cause the browser to hang, we don't process JavaScript-to-Java calls when the Java plugin is launched from plugin-container.exe (the default behavior for Firefox 42) and the applet status is not Ready(2). If the applet is not ready (the status is not 2), we don't execute the actual Java method and only return null.

If the plugin is launched from plugin-container.exe, do not use JavaScript-To-Java calls that may require more than 11 seconds(the default value of dom.ipc.plugins.hangUITimeoutSecs) to be completed or show a modal dialog during JavaScript-To-Java call. In this case, the main browser thread must be blocked, which might cause the browser to hang and the plugin to terminate.

Workaround (for Firefox 42):
User’s can set dom.ipc.plugins.enabled=false. The side effect of this workaround is that it changes the setting for all plugins.

JDK-8144079 (not public)

New attribute for JMX RMI JRMP servers specifies a list of class names to use when deserializing server credentials
A new java attribute has been defined for the environment to allow a JMX RMI JRMP server to specify a list of class names. These names correspond to the closure of class names that are expected by the server when deserializing credentials. For instance, if the expected credentials were a List<string>, then the closure would constitute all the concrete classes that should be expected in the serial form of a list of Strings.

By default, this attribute is used only by the default agent with the following:

 {   
   "[Ljava.lang.String;",   
   "java.lang.String" 
 } 

Only arrays of Strings and Strings will be accepted when deserializing the credentials.

The attribute name is:

"jmx.remote.rmi.server.credential.types"

The following is an example of a user starting a server with the specified credentials class names:

Map<String, Object> env = new HashMap<>(1);
 env.put ( 
 "jmx.remote.rmi.server.credential.types",
   new String[]{
   String[].class.getName(),
   String.class.getName()
   }
   );
   JMXConnectorServer server
   = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer);

The new feature should be used by directly specifying: 
 "jmx.remote.rmi.server.credential.types" 

JDK-8144430 (not public)

New certificates added to root CAs
Eight new root certificates have been added :

QuoVadis Root CA 1 G3
alias: quovadisrootca1g3
DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM

QuoVadis Root CA 2 G3
alias: quovadisrootca2g3
DN: CN=QuoVadis Root CA 2 G3

QuoVadis Root CA 3 G3
alias: quovadisrootca3g3
DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM

DigiCert Assured ID Root G2
alias: digicertassuredidg2
DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US

DigiCert Assured ID Root G3
alias: digicertassuredidg3
DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US

DigiCert Global Root G2
alias: digicertglobalrootg2
DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US

DigiCert Global Root G3
alias: digicertglobalrootg3
DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US

DigiCert Trusted Root G4
alias: digicerttrustedrootg4
DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US

See JDK-8145954 and JDK-8145955


Changes in Java SE 7u99 b31

 

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

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

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

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

IANA Data 2016a

JDK 7u99 contains IANA time zone data version 2016a. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_99
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u99) will expire with the release of the next critical patch update scheduled for April 19, 2016.

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

Notes

The demos, samples, and Documentation bundles for 7u99 are not impacted by the Security Alert for CVE-2016-0636, so version 7u95 demos, samples, and Documentation bundles remain the most up to-date version until the April Critical Patch Update release.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.


Changes in Java SE 7u97 b33

 

Bug Fixes

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

Changes in Java SE 7u97 b32

 

Bug Fixes

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

Changes in Java SE 7u97 b31

 

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

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

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

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

IANA Data 2015g

JDK 7u97 contains IANA time zone data version 2015g. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_95
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u97) will expire with the release of the next critical patch update scheduled for April 19, 2016.

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

Notes

Oracle strongly recommends that Java users who have downloaded affected versions and plan future installations with these downloaded versions discard these old downloads. Java users who have installed the January 2016 Critical Patch Update versions of Java SE 6, 7, or 8 need take no action. Java users who have not installed the January 2016 Critical Patch Update versions of Java SE 6, 7, or 8 should upgrade to the Java SE 6, 7, or 8 releases from the Security Alert for CVE-2016-0603.

The demos, samples, and Documentation bundles for 7u97 are not impacted by the Security Alert for CVE-2016-0603, so version 7u95 demos, samples, and Documentation bundles remain the most up to-date version until the April Critical Patch Update release.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see the Oracle Java SE Critical Patch Update Advisory.


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

The following sections summarize changes made in all Java SE 7 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version


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


Changes in Java SE 7u95 b32

 

Bug Fixes

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

Changes in Java SE 7u95 b31

 

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

Changes in Java SE 7u95 b13

 

Bug Fixes

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

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


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

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

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

IANA Data 2015g

JDK 7u95 contains IANA time zone data version 2015g. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_95
6 1.6.0_111

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u95) will expire with the release of the next critical patch update scheduled for April 19, 2016.

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

New Features and Changes

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

*MD5 now disabled for X509 Certificate validating*
MD5 must not be used for digital signatures where collision resistance is required. To prevent the use of X.509 certificates that include an MD5-based digital signature algorithm, MD5 has been added to the jdk.certpath.disabledAlgorithms security property. Applications should upgrade or replace certificates that include an MD5-based digital signature.

Reversing this change is possible by removing MD5 from the jdk.certpath.disabledAlgorithms security property in the java.security file. This is not recommended.

JDK-8141287 (not public)

Disable MD5withRSA signature algorithm in the JSSE provider
The MD5withRSA signature algorithm is now considered insecure and should no longer be used. Accordingly, MD5withRSA has been deactivated by default in the Oracle JSSE implementation by adding "MD5withRSA" to the "jdk.tls.disabledAlgorithms" security property. Now, both TLS handshake messages and X.509 certificates signed with MD5withRSA algorithm are no longer acceptable by default. This change extends the previous MD5-based certificate restriction ("jdk.certpath.disabledAlgorithms") to also include handshake messages in TLS version 1.2. If required, this algorithm can be reactivated by removing "MD5withRSA" from the "jdk.tls.disabledAlgorithms" security property.

JDK-8144773 (not public)

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

See JDK-8076369.

Bug Fixes

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

Nondeterministic wrong answer on arithmetic corrected
When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed.

See JDK-8072753.

Running jps as root does not show all information
After the fix of JDK-8050807 (fixed in 8u31, 7u75 and 6u91), running jps as root did not show all the information from Java processes started by other users on some systems. This has now been fixed.

See JDK-8075773.

JFR reports abnormally high machine CPU consumption on Linux
On Linux kernels 2.6 and later, the JDK would include time spent waiting for IO completion as "CPU usage". During periods of heavy IO activity, this could result in misleadingly high values reported as CPU consumption in various tools like Flight Recorder and performance counters. This issue has been resolved.

See JDK-8133527.

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

See JDK-8078495.


Changes in Java SE 7u91 b33

 

Bug Fixes

BugId Category Subcategory Description
8136759
(Confidential)
deploy deployment_toolkit Regression in Applet startup time with Internet Explorer on 8u60 and 8u65-b14
8133523 deploy plugin _releaseObject called from wrong thread
8076369 security-libs javax.net.ssl Introduce the jdk.tls.client.protocols system property for JDK 7u

Regression in Applet startup time fixed
JDK-8080977 introduced delay on applet launch. The delay appears only on IE and lasts about 20 seconds. JDK-8136759 removed this delay.

See JDK-8136759


Changes in Java SE 7u91 b32

 

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

Bug Fixes

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

Changes in Java SE 7u91 b17

 

Bug Fixes

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

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

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

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

IANA Data 2015f

JDK 7u91 contains IANA time zone data version 2015f. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_91
6 1.6.0_105

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u91) will expire with the release of the next critical patch update scheduled for January 19, 2016.

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

Notes

When running on OSX 10.11 "El Capitan", when SIP is enabled, certain environment variables intended for debugging applications, such as DYLD_LIBRARY_PATH, may be stripped from the environment when running Java from the command line or when double-clicking a JAR file. Applications should not rely on these variables in a production environment, they are only intended for debugging during development.

 

New Features and Changes

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

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


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

See JDK-8080637.

Support ISO 4217 "Current funds codes" table (A.2)
This enhancement adds support for ISO 4217 table A.2 fund codes. Previously the JDK only supported those currencies listed in table A.1.

See JDK-8074350.

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

See JDK-8062834.

Bug Fixes

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

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

Use Safe Prime Diffie-Hellman Groups
In the JDK SSL/TLS implementation (SunJSSE provider), safe prime Diffie-Hellman groups are used by default. Users can customize Diffie-Hellman groups with the security property, "jdk.tls.server.defaultDHEParameters".

Kerberos changes for applications running with security manager
This JDK release introduces some changes to how Kerberos requests are handled when a security manager is present.

Note that if a security manager is installed while a KerberosPricipal is being created, a {@link ServicePermission} must be granted and the service principal of the permission must minimally be inside the {@code KerberosPrincipal}'s realm.

For example, if the result of {@code new KerberosPrincipal("user")} is {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted.

Also note that if a single GSS-API principal entity that contains a Kerberos name element without providing its realm is being created via the org.ietf.jgss.GSSName interface and a security manager is installed, then this release introduces a new requirement. A {@link javax.security.auth.kerberos.ServicePermission ServicePermission} must be granted and the service principal of the permission must minimally be inside the Kerberos name element's realm.

For example, if the result of {@link GSSManager#createName(String, Oid) createName("user", NT_USER_NAME)} contains a Kerberos name element {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted. Otherwise, the creation will throw a {@link GSSException} containing the {@code GSSException.FAILURE} error code.

JDK-8048030 (not public)

Hotspot should use PICL interface to get cacheline size on SPARC

The libpicl library is now required on Solaris/SPARC to determine the size of the cache lines. In case the library is not present or the PICL service is not available the JVM will display a warning and compiler optimizations that utilize the BIS (Block Initializing Store) instruction will be turned off.

See JDK-8056124.

Preloading libjsig.dylib causes deadlock when signal() is called
Applications need to preload the libjsig library to enable signal chaining. Previously, on OS X, after libjsig.dylib was preloaded, any call from native code to signal() caused a deadlock. This has been corrected.

See JDK-8072147.


Changes in Java SE 7u85 b34

 

Bug Fixes

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

Changes in Java SE 7u85 b33

 

Bug Fixes

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

Changes in Java SE 7u85 b31

 

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

Bug Fixes

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

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

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

Highlights

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

IANA Data 2015d

JDK 7u85 contains IANA time zone data version 2015d. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_85
6 1.6.0_101

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u85) will expire with the release of the next critical patch update scheduled for October 20, 2015.

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

JavaFX Release Notes

This JDK release includes JavaFX version 2.2.85.

New Features and Changes


Ephemeral DH keys less than 768 bits deactivated
Ephemeral DH keys less than 768 bits are deactivated in JDK. New algorithm restriction DH keySize < 768 is added to Security Property jdk.tls.disabledAlgorithms.

JDK-8076328 (not public).



IBM1166 character set now available
This release adds IBM1166 character set. It provides support for cyrillic multilingual with euro for Kazakhstan. Aliases for this new character set include cp1166,ibm1166, ibm-1166, and 1166.
See JDK-8071447.



Operating system's restricted environment (Native Sandbox)

JDK 8u51 introduced the following changes to Native Sandbox:

  • Native sandbox is available on Windows platform only.

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

    Native sandbox is disabled by default.

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

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

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

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

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

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

Support stronger strength ephemeral DH keys in the SunJSSE provider

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

See 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

See 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

See 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 

See 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

See 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

See 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

See 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

See 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

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

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

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

See JDK-8067696 (not public).

 


Changes in Java SE 7u80 b35

 

Bug Fixes

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

Changes in Java SE 7u80 b34

 

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

Changes in Java SE 7u80 b33

 

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

Changes in Java SE 7u80

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


Changes in Java SE 7u76 b38

 

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

Changes in Java SE 7u76 b37

 

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

Bug Fixes

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

Changes in Java SE 7u76 b36

 

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

Changes in Java SE 7u76 b35

 

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

Bug Fixes

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

Changes in Java SE 7u76 b34

 

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

Changes in Java SE 7u76 b33

 

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

Bug Fixes

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

Changes in Java SE 7u76 b32

 

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

Bug Fixes

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

Changes in Java SE 7u76

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


Changes in Java SE 7u72 b33

 

Bug Fixes

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

Changes in Java SE 7u72 b32

 

Bug Fixes

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

Changes in Java SE 7u72 b31

 

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

Changes in Java SE 7u72

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


Changes in Java SE 7u67 b34

 

Bug Fixes

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

Changes in Java SE 7u67 b31

 

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

Changes in Java SE 7u67

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


Changes in Java SE 7u65 b33

 

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

Bug Fixes

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

Changes in Java SE 7u65

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


Changes in Java SE 7u60 b33

 

Bug Fixes

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

Changes in Java SE 7u60 b32

 

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

Bug Fixes

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

Changes in Java SE 7u60

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


Changes in Java SE 7u55 b35

 

Bug Fixes

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

Changes in Java SE 7u55 b33

 

Bug Fixes

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

Changes in Java SE 7u55 b32

 

Bug Fixes

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

Changes in Java SE 7u55 b31

 

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

Changes in Java SE 7u55

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


Changes in Java SE 7u51 b33

 

Bug Fixes

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

Changes in Java SE 7u51 b32

 

Bug Fixes

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

Changes in Java SE 7u55 b31

 

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

Changes in Java SE 7u51

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


Changes in Java SE 7u45 b34

 

Bug Fixes

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

Changes in Java SE 7u45 b33

 

Bug Fixes

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

Changes in Java SE 7u45 b32

 

Bug Fixes

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

Changes in Java SE 7u45 b31

 

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

Changes in Java SE 7u45

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


Changes in Java SE 7u40 b62

 

Bug Fixes

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

Changes in Java SE 7u40

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


Changes in Java SE 7u25 b35

 

Bug Fixes

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

Changes in Java SE 7u25 b34

 

Bug Fixes

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

Changes in Java SE 7u25 b33

 

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

Bug Fixes

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

Changes in Java SE 7u25

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


Changes in Java SE 7u21 b31

 

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

Bug Fixes

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

Changes in Java SE 7u21

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


Changes in Java SE 7u17 b32

 

Bug Fixes

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

Changes in Java SE 7u17 b31

 

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

Changes in Java SE 7u17

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


Changes in Java SE 7u15

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


Changes in Java SE 7u13

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


Changes in Java SE 7u11 b32

 

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

Changes in Java SE 7u11

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


Changes in Java SE 7u10 b31

 

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

Changes in Java SE 7u10

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


Changes in Java SE 7u9 b32

 

Bug Fixes

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

Changes in Java SE 7u9 b31

 

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

Changes in Java SE 7u9

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


Changes in Java SE 7u7 b32

 

Bug Fixes

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

 


Changes in Java SE 7u7

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


Changes in Java SE 7u6

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


Changes in Java SE 7u5

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


Changes in Java SE 7u4

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

Version Name Changed

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

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

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


Changes in Java SE 7u3

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


Changes in Java SE 7u2

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


Changes in Java SE 7u1

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


Java SE 7

Java SE 7 Release Notes


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