Java SE 7 Update 45 Released

Java SE 7 Update 45 and Java SE Embedded 7 Update 45 are now available for download. These releases include new Date/Time capability and security updates. Release notes are here.

Java SE 7 Update 45 Changes

New Date/Time Capability

The java.util.TimeZone.setDefault(TimeZone) method has been changed to throw aSecurityException if the method is called by any code with which the security manager'scheckPermission call denies PropertyPermission("user.timezone", "write"). The new system property jdk.util.TimeZone.allowSetDefault (a boolean) is provided so that the compatible behavior can be enabled. The property will be evaluated only once when thejava.util.TimeZone class is loaded and initialized.

Security Changes


This release introduces a new warning when web pages initiate LiveConnect calls into an RIA without being properly signed/configured. Planned for the future, Java SE 7 Upate 51, January 2014 will introduce a requirement that all RIAs distributed publicly be signed by a valid certificate and contain a new Permissions attribute. These changes only affect Applet & Web Start applications (Rich Internet Applications). They do not affect other areas, such as: server-side, embedded, or client. Read more in the blog LiveConnect changes in 7u45.

Protections Against Unauthorized Redistribution of Java Applications

Starting with 7u45, application developers can specify new JAR manifest file attributes:

Application-Name: This attribute provides a secure title for your RIA.

Caller-Allowable-Codebase: This attribute specifies the codebase/locations from which JavaScript is allowed to call Applet classes.

JavaScript to Java calls will be allowed without any security dialog prompt only if:

  • JAR is signed by a trusted CA, has the Caller-Allowable-Codebase manifest entry and JavaScript runs on the domain that matches it.
  • JAR is unsigned and JavaScript calls happens from the same domain as the JAR location.

The JavaScript to Java (LiveConnect) security dialog prompt is shown once per AppletclassLoader instance.

Application-Library-Allowable-Codebase: If the JNLP file or HTML page is in a different location than the JAR file, the Application-Library-Allowable-Codebase attribute identifies the locations from which your RIA can be expected to be started.

If the attribute is not present or if the attribute and location do not match, then the location of the JNLP file or HTML page is displayed in the security prompt shown to the user.

Note that the RIA can still be started in any of the above cases.

Developers can refer to JAR File Manifest Attributes for more information.

Restore Security Prompts

A new button is available in the Java Control Panel (JCP) to clear previously remembered trust decisions. A trust decision occurs when the user has selected the Do not show this again option in a security prompt. To show prompts that were previously hidden, click Restore Security Prompts. When asked to confirm the selection, click Restore All. The next time an application is started, the security prompt for that application is shown.

See Restore Security Prompts under the Security section of the Java Control Panel.

JAXP Changes

Starting from JDK 7u45, the following new processing limits are added to the JAXPFEATURE_SECURE_PROCESSING feature.

  • totalEntitySizeLimit
  • maxGeneralEntitySizeLimit
  • maxParameterEntitySizeLimit

For more information, see the new Processing Limits lesson in the JAXP Tutorial

Key Links

Download Java SE 7 Update 45

Release Notes

LiveConnect Changes in 7u45

What To Do If Your Applet is Blocked or Warns of "Mixed Code?"


Not mentioned is that WebStart applications can no longer access 'insecure' system properties from the jnlp file ('insecure' are all properties which do not start with the prefix 'jnlp.').
See here:

Posted by PeJoBo on October 18, 2013 at 04:03 AM PDT #

Two changes to WebStart-based applications are not mentioned here and breaks the compatibility with previous releases:
1-System.getProperties() does not return all <property> in JNLP file
2-ClassLoader.getResources(String) does not look into the entire classpath unless the RIA is signed with JNLP template

Please focus on the "breaks the compatibility" part, because most of our customers will not be able to update the JRE because of that. And no easy way to "patch" the software released and installed in customer's server hosts.

Posted by Daniemar on October 22, 2013 at 09:39 PM PDT #

There are a few work-arounds posted on that bug. For JNLPs residing outside the signed JAR (e.g. dynamically generated JNLPs), you can prepend "jnlp." to the beginning of the property name. Otherwise you can place the JNLP within the JAR before signing & timestamping it. The filename for that is JNLP-INF/APPLICATION.JNLP.

Posted by costlow on October 23, 2013 at 09:46 AM PDT #

I know these options, and that's what we are actually doing, but this means changing the code and create a patch release for any of the released software affected by this problem, deliver the patches to the customers and install them in their servers. Today, we're asking users to not install the latest JRE but reach out all of them is not really easy, and in some cases it may be troublesome to uninstall the JRE it and rollback to one of the previous JRE.

(you may reach me via email, if want some extra details)

Posted by Daniemar on October 23, 2013 at 11:21 AM PDT #

If system properties were not exactly required (e.g. application specific settings) you can always pass them in as arguments instead.

Posted by guest on November 01, 2013 at 10:45 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Insider News from the Java Team at Oracle!



« June 2016