The full version string for this update release is 1.7.0_51-b13 (where "b" means "build"). The version number is 7u51.
This update release contains several enhancements and changes including the following:
JDK 7u51 contains Olson time zone data version 2013h. For more information, refer to Timezone Data Versions in the JRE Software.
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u51 are specified in the following table:
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
7 | 1.7.0_51 |
6 | 1.6.0_71 |
5.0 | 1.5.0_61 |
For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.
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 7u51) will expire with the release of the next critical patch update scheduled for April 15, 2014.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 7u51) on May 15, 2014. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
JavaFX is now part of JDK. JDK 7u51 release includes JavaFX version 2.2.51.
Jarsigner updated to encourage timestamping
Timestamping for a signed jar is now strongly recommended. The Jarsigner tool will print out an informational warning at signing or verifying when timestamp is missing. For more information, see Signing JAR Files.
See 8023338.
Changes to Security Slider:
The following changes to Security Slider were included in this release(7u51):
For more information, see Java Control Panel documentation.
Prompt users to clear previously remembered decisions:
In JDK 7u51, users are given an option to restore the security prompts, for any prompts that were hidden prior to installing the latest release. For more information, see Install Documentation for Windows.
It is recommended that users restore security prompts after every 30 days to ensure better protection.
Note: This option is offered only during Auto update on Mac OS.
Exception Site List:
The Exception Site List feature allows end users to run Java applets and Java Web Start applications that do not meet the latest security requirements. Rich Internet Applications that are hosted on a site in the exception site list are allowed to run with the applicable security prompts.
For more information, see Exception Site List documentation.
The default socket permissions assigned to all code including untrusted code have been changed in this release. Previously, all code was able to bind any socket type to any port number greater than or equal to 1024. It is still possible to bind sockets to the ephemeral port range on each system. The exact range of ephemeral ports varies from one operating system to another, but it is typically in the high range (such as from 49152 to 65535). The new restriction is that binding sockets outside of the ephemeral range now requires an explicit permission in the system security policy.
Most applications using client tcp sockets and a security manager will not see any problem, as these typically bind to ephemeral ports anyway. Applications using datagram sockets or server tcp sockets (and a security manager) may encounter security exceptions where none were seen before. If this occurs, users should review whether the port number being requested is expected, and if this is the case, a socket permission grant can be added to the local security policy, to resolve the issue.
See 8011786 (not public).
In JDK 7u51, a change has been made in JAXP Xalan Extension functions to always use the default DOM implementation when Security Manager is present. This change affects the NodeSet
created by DOM Document.
Before this change, the DOM implementation is located through the DOM factory lookup process. With this change, when security is enabled, the lookup process is skipped and the default DOM implementation is used.
This change will only affect those applications that use a 3rd party DOM implementation. In general, the NodeSet
structure is expected to be compatible with that of the JDK default implementation.
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 7u51 Bug Fixes page.
The following are some of the notable bug fixes in this release:
The jarsigner
tool prints out more messages when there are severe warnings and -strict
is on. For details, see the jarsigner
tool documentation (Windows)(Solaris/Linux).
See 8024302 (not public).
JDK
com.sun.corba.se.**
should be on restricted package list.The JDK internal package com.sun.corba.se
and its sub-packages have been added to the restricted package list and therefore cannot be used directly when running with a security manager.
Workaround:
Applications running with a security manager that make direct use of classes in these JDK internal packages, need to adjust their security policy to grant access. See Java Security Policy Files documentation.
See 8021257.
On Linux, failures when allocating large pages can lead to crashes. When running JDK 7u51 or later versions, the issue can be recognized in two ways:
Before the crash happens one or more lines similar to this will have been printed to the log:
os::commit_memory(0x00000006b1600000, 352321536, 2097152, 0) failed;
error='Cannot allocate memory' (errno=12); Cannot allocate large pages, falling back to regular pages
If a hs_err file is generated it will contain a line similar to this:
Large page allocation failures have occurred 3 times
The problem can be avoided by running with large page support turned off, for example by passing the "-XX:-UseLargePages"
option to the java binary.
See 8007074 (not public).
For sandbox app, a second certificate revocation check is always performed after accepting security dialog, ignoring that fact that user already accepted the certificate. If there are network connection problems, such as when a proxy is turned off, the revocation check can take a long time, before java.net.SocketTimeoutException
is thrown.
Workaround:
User can disable certificate revocation checks by using Java Control Panel:
See 8029260 (not public).
SwingUtlities.invokeLater
or invokeAndWait
throw an NPE.On platforms running 7u25 or later, webstart applications that use RMI with SwingUtlities.invokeLater
throw an NPE.
Workaround:
If started from the command line, the program works. Alternately, the user can use the following helper class:
import javax.swing.SwingUtilities;
import java.util.concurrent.*;
final public class SwingRmiHelper {
private static ExecutorService exec;
private SwingRmiHelper() {
}
private static ExecutorService getExecutor() {
if (exec == null) {
throw new IllegalStateException(
"Class is not initialized. You must invoke " +
"initialize in application's main method for
Java Web Start application" +
" and in Applet.init for Applets.");
}
return exec;
}
public static void initialize() {
exec = Executors.newSingleThreadExecutor();
}
public static void invokeLater(final Runnable runnable) {
getExecutor().execute(new Runnable() {
@Override
public void run() {
SwingUtilities.invokeLater(runnable);
}
});
}
public static void invokeAndWait(final Runnable runnable)
throws ExecutionException, InterruptedException {
getExecutor().submit(new Callable<Object>() {
@Override
public Object call() throws Exception {
SwingUtilities.invokeAndWait(runnable);
return null;
}
}).get();
}
}
Before the first usage of the above class, the following steps should be executed:
initialize
method must be called in the main method for Java web start applications and in Applet.init
for Applets.SwingUtilities.invokeLater/invokeAndWait(runnable)
in all methods that can be invoked via RMI with SwingRmiHelper.invokeLater/invokeAndWait(runnable)
.See 8017770.
JAR files signed with jarsigner
from Java SE 1.4 or earlier versions, will not be signed properly when they contain resource files in META-INF, such as license docs or images.
For security purposes, such JARs are no longer considered to be validly signed. Currently applets using these JARs will fail to load, with no indication of the cause to the end user.
The only workaround is to re-sign the JAR with the current version of jarsigner.
See 8026746 (not public).
If the signed main jar fails to contain the required "Permissions" manifest file entry,the application should be blocked. However the security dialog is shown first, asking user permission to run the application, before the application is blocked.
See 8027821.
An additional permission may be needed in order to bring up the Java DB network server. In particular, the startup scripts in <db/bin>
may fail to boot the network server. This is a result of the "Better applet networking" changes made by 8011787 (not public).
While attempting to boot, the network server may fail and raise the following error:
access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied
("java.net.SocketPermission" "localhost:1527" "listen,resolve")
To fix this problem, you must bring up the network server with a security policy which includes the missing permission. Instead of booting the network server as:
java org.apache.derby.drda.NetworkServerControl start
boot the network server as follows:
java -Djava.security.manager -Djava.security.policy=${yourPolicyFile}
org.apache.derby.drda.NetworkServerControl start
where ${yourPolicyFile}
is a file containing a customized version of the policy file described in the Java DB Admin Guide section titled Basic Network Server security policy. You must customize that generic policy file to fit your application. In addition, you must add the following permission to the permissions block granted to the ${derby.install.url}derbynet.jar
codebase:
permission java.net.SocketPermission "localhost:${port}", "listen";
where ${port}
should be replaced by the port number where the network server listens for incoming connection requests. By default, that is port 1527.
For more information on Java DB security policies, see the Java DB Admin Guide sections titled Network Server security and Running the Network Server under the security manager.
If you are using replication, a similar permission must be granted to the security policy for the slave server. Add the following permission to the ${derby.install.url}derby.jar
codebase:
permission java.net.SocketPermission "localhost:${slavePort}", "listen";
where ${slavePort}
should be replaced by the port number where the slave server listens for incoming connection requests (typically 4851). For more information on the security policy for the slave server, see the Java DB Admin Guide section titled Replication and security.
See 8011787 (not public).
CLSID
to trigger loading of an applet does not work with certain JRE family versions.If you use the family CLSID
to trigger loading of an applet with a certain JRE family version, the family CLISD
will be ignored and the latest JRE version installed on your system is used to load the applet instead. Family CLSID
is specific to Internet Explorer. The workaround is to use the java_version
applet parameter or the version
attribute of the Java element in JNLP file instead.
See 8025981 (not public).
A straightforwar workaround is to disable FIPS mode of SunJSSE provider.
An alternative workaround is to disable the use of RSA key exchange in SSL/TLS protocols. This issue only happens to RSA key exchange based SSL/TLS cipher suites. To workaround this issue, applications can use DHE/ECDHE cipher suites instead (for example, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, etc.). Please refer to JSSE Reference Guide about how to customize SSL/TLS cipher suites.
See 8028192 (not public).
On Mac OS 10.9, when a scheduled Java (auto) update is initiated, the installer may become unresponsive.
The following workarounds should be performed by users facing this issue: