JRE Expiration Date

Blacklist Entries

Order of Signing the Jar Files

In JDK 7u25, a bug that incorrectly treated jars in non-jnlp applets with an unsigned index.list entry as properly signed if the rest of the jar was signed, has been fixed. As a result of this fix, signed jars that contained an unsigned index.list will now either trigger the unsigned code warning dialog or be blocked depending on the security level and whether the JRE is above or below the security baseline.

To properly sign a jar, index entries must be created before the jar is signed. For more information see 8016771.

Local Applets return NULL for codebase

Beginning with JDK 7u25, an applet's getCodeBase() method will return NULL when the applet is running from the local file system.

Before signed Java applets and Java Web Start applications are run, the signing certificate is checked to ensure that it has not been revoked. Advanced options in the Java Control Panel(JCP) can be set to manage the checking process. For more information on these options, see the Advanced section of the Java Control Panel documentation.

Under normal circumstances revocation checking will have a slight impact on startup performance for applets and web start applications. Enterprises with managed networks and without access to the Internet (resulting in no access to the revocation services provided by Certificate Authorities) will see a significant delay in startup times.

To avoid such delay, they may choose to disable on line revocation checking through the JCP. Note that disabling on line revocation checking should only be considered in managed environments as it decreases security protections.

JDK 7u25 release introduces the permissions and codebase attributes in the JAR Manifest File. These attributes are used to verify that the application is requesting the correct permissions level and is accessed from the correct location. See Preventing the Repurposing of an Application document.

Developers are advised to utilize at least the new permissions attribute, and if possible the codebase attribute as well. In future releases, applications that do not include these protections may be blocked or subjected to additional warning dialogs.

LiveConnect calls from JavaScript to Java API are blocked when the Java Control Panel security slider is set to Very High level, or when the slider is at the default High level and the JRE has either expired or is below the security baseline.

To avoid potential security issues with XML signatures, a secure validation mode has been added whereby signatures that contain potentially hostile constructs are rejected and not processed.

For this purpose, the following new private property is added to the JDK:

org.jcp.xml.dsig.secureValidation

The property can be set by an application by calling the setProperty method of the javax.xml.crypto.dsig.dom.DOMValidateContext class with the name of the property above and a Boolean value.

When set to true, this property instructs the implementation to process XML signatures more securely. This will set limits on various XML signature constructs to avoid conditions such as denial of service attacks.

When not set, or set to false, the property instructs the implementation to process XML signatures according to the XML Signature specification without any special limits.

If a SecurityManager is enabled, the property is set to true by default.

Alternatively, for convenience of users and for those who have further modified the generated documentation, Oracle provides the Java API Documentation Updater, a repair-in-place tool.

Source code is available with the download if you have a non-standard environment. The Java API Documentation Updater Tool is a separate download and not included in any JDK/JRE bundles. Please also see important information related to the javadoc tool in the Known Issues section.

The implementation of the networking APIs has been changed on Windows to use the SO_EXCLUSIVEADDRUSE socket option by default. This change is necessary to address anomalies that arise when using both IPv4 and IPv6 applications that require to bind to the same port.

This change may cause issues for applications that rely on the ability to have multiple processes bound to the same address and port. When such issues occur, then use sun.net.useExclusiveBind system property as a temporary workaround to restore legacy behavior.

On the Windows platform, the decoding of command strings specified to java.lang.ProcessBuilder and the exec methods defined by java.lang.Runtime, has been made stricter since JDK 7u21. This may cause problems for applications that are using one or more of these methods with commands that contain spaces in the program name, or are invoking these methods with commands that are not quoted correctly. For more information see JDK 7u21 Release Notes.

In JDK 7u25, the system property jdk.lang.Process.allowAmbigousCommands can be used to relax the checking process and may be used as a workaround for some applications that are impacted by the stricter validation. The workaround is only effective for applications that are run without a security manager. To use this workaround, either the command line should be updated to include -Djdk.lang.Process.allowAmbigousCommands=true or the java application should set the system property jdk.lang.Process.allowAmbigousCommands to true.

Quoting and escaping commands on Windows platform is complicated. The following examples may be useful to developers if they are impacted by the stricter validation.

Example 1: The application needs to be launched with C:\Program Files\foo.exe.

Both signed and unsigned applets with local or remote policy files with ALL permissions were not behaving as expected.

The behavior was due to honoring JCP security levels. The following summarizes the expected behavior:

All applets and applications will show security warning dialog (unsigned/signed/signed-sandbox) even when there is a local/remote policy file with all_permissions.

All applets and applications will honor all levels of security slider even when there is a local/remote policy file with all_permissions.

A local or remote policy file should only effect execution of applets and applications i.e. to provide proper set of sandbox permissions at the time of execution as per policy settings.

Area: security-libs/java.securitySynopsis: Improve on checking order

The implementation of java.security.AccessController.doPrivileged(PrivilegedAction, AccessControlContext) and AccessController.doPrivileged(PrivilegedExceptionAction, AccessControlContext) have been modified to improve security.

Specifically, if a security manager is installed, the AccessControlContext is not created by system code and the caller's ProtectionDomain has not been granted the security permission (java.security.SecurityPermission) createAccessControlContext, then the action is performed with no permissions.

Area: core-libs/java.util.loggingSynopsis: Remove the stack search for a resource bundle for Logger to use

The java.util.logging.Logger class no longer does stack walk search for a logger's resource bundle. The stack walk search was intended as a temporary measure to allow containers to transition to using the context class loader and was specified to be removed in a future release. It will use the thread context class loader (if not set, use the system class loader) to look up the resource bundle and, if not found, it will fall back to use the class loader of the caller class that creates the Logger instance (via the Logger.getLogger() and Logger.getAnonymousLogger() method with a given resource bundle name).

If applications have not transitioned to use the thread context class loader as specified in the Logger class specification and depend on the temporary stack walk search behavior, java.util.MissingResourceException exception will be thrown if it fails to find the resource bundle.

The workaround is to set a system property, -Djdk.logging.allowStackWalkSearch=true, at the command-line to enable the stack walk search. This workaround is also temporary and will be removed in a future 7 update release. It is strongly recommended for applications to transition and remove the dependency on the stack walk search.

Known Issues

Area: tools/javadocSynopsis: Regression: Javadoc i18n regression

Problem:

If a package name contains non-ascii characters, the 'Frames' links on a package-summary.html page loaded in the main pane of a frames layout will load the overview-summary.html page rather than reload the package-summary.html page.

Work-around:

Do not use the 'Frames' links of a package-summary page already loaded in the main pane.

To get back to the package-summary page, click the desired package name link in upper left pane, then click the package name link in the lower left pane.