Java™ SE Development Kit 7, Update 51 (JDK 7u51)

Update Release Notes

Update Release Notes Index

---

Java™ SE Development Kit 7, Update 51 (JDK 7u51)

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

Highlights

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

• JavaFX Release Notes
• New Features and Changes

Olson Data 2013h

JDK 7u51 contains Olson time zone data version 2013h. 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 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.

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 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 Release Notes

JavaFX is now part of JDK. JDK 7u51 release includes JavaFX version 2.2.51.

New Features and Changes

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

• Block Self-Signed and Unsigned applets on High Security Setting
• Require Permissions Attribute for High Security Setting
• Warn users of missing Permissions Attributes for Medium Security Setting

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.

Change in Default Socket Permissions

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

Change in JAXP Xalan Extension Functions

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

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

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

Area: tools/jar
Synopsis: Clarify jar verifications

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

Known Issues

JDK

Area:otherlibs/corba
Synopsis: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 Filesdocumentation.

See 8021257.

Area: hotspot/gc
Synopsis: Crashes due to failure to allocate large pages.

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

Area: deploy/plugin
Synopsis: It takes a long time to load app after accepting a multi-click dialog caused by "the certificate revocation site cannot be accessed"

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:

• Select tab "Advanced"
• Find the option named "Performs certificate revocation checks on"
• Set it to "Do not check(not recommended)"

See 8029260 (not public).

Area: deploy/webstart
Synopsis: Webstart applications that use RMI with SwingUtlities.invokeLater orinvokeAndWait throw an NPE.

On platforms running 7u25 or later, webstart applications that use RMI withSwingUtlities.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

Before the first usage of the above class, the following steps should be executed:

• The initialize method must be called in the main method for Java web start applications and in Applet.init for Applets.
• The user must replace all usages ofSwingUtilities.invokeLater/invokeAndWait(runnable) in all methods that can be invoked via RMI with SwingRmiHelper.invokeLater/invokeAndWait(runnable).

See 8017770.

Area: deploy/plugin
Synopsis: Regression: JARSigningException exception throws when use 7u jarsigner.

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

Area: deploy/plugin
Synopsis: For signed jars without manifest "Permissions", there is still a security warning dialog before Application Error (or Blocked) dialog.

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.

Area: other-libs/javadb
Synopsis: Additional permission needed to run Java DB network server

An additional permission may be needed in order to bring up the Java DB network server. In particular, the startup scripts in  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 titledNetwork 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).

Area: Deployment/Plugin
Synopsis: Using the family 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 thejava_version applet parameter or the version attribute of the Java element in JNLP file instead.

See 8025981 (not public).

Area: security-libs/javax.net.ssl
Synopsis: When using RSA client key exchange in SSL/TLS protocols, SunJSSE provider cannot work in FIPS 140 compliant mode. This issue does not impact the default mode of SunJSSE.

A straightforwar workaround is to disable FIPS mode of SunJSSE provider. For more information see, FIPS 140 Compliant Mode for SunJSSE.

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

Area: install/install
Synopsis: [macosx] Scheduled AU - cannot auto update on Mac 10.9

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:

• Manually install the updated pkg from java.com
• Trigger an update through the Java Control Panel

- wong chee tat :)