Update Release Notes

Java™ SE 7 Update 2

The full internal version number for this update release is 1.7.0_02-b13 (where "b" means "build"). The external version number is 7u2.

Highlights

This update release contains functionality enhancements for Java applications:

• New JVM (Java HotSpot Virtual Machine, version 22) that improves reliability and performance
• Support for Oracle Solaris 11
• Support for Firefox 5 and later
• JavaFX is included with Java SE

Olson Data 2011l

Java SE 7u2 contains Olson time zone data version 2011l. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java SE platform at the time of the release of Java SE 7u2 are specified in the following table:

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

Additional Certified System Configurations

For Java SE 7u2, the following system configurations have been certified:

• Oracle Solaris 11
• Firefox 5, 6, 7, and 8

Refer to the Oracle Certified System Configurations page for more information.

Enhanced Security Through Old Release Warnings

If users have a version of Java on their systems that is below the security baseline, a warning message is displayed before an application or an applet can be run.

Demos and Samples in a Separate Bundle

In Java SE 7u2, demos and samples have been removed from the JDK installers and placed into separate bundles:

• On Windows, demos and samples are available as .zip files.
• On Solaris, demos and samples are available as separate .tar.z compressed packages and .tar.gz compressed binaries.
• On Linux, demos and samples are available as separate .rpm installers or .tar.gz compressed binaries.

Like other 64-bit bundles on Solaris and Linux, the 64-bit demos and samples bundles on Solaris and Linux expect the 32-bit demos and samples bundles to also be installed.

Java SE Includes JavaFX

The JDK includes the JavaFX SDK. See JavaFX 2.0.2 Release Notes for more information.

Deployment Updates

This release introduces the following improvements for web-deployed applications:

• Non-blocking installation of JRE and JavaFX using Deployment Toolkit: The web page continues to accept user input while Deployment Toolkit downloads and installs the required components. See 7052499 for details.
• Reduced footprint of signed JAR files: This release provides a new signing method that enables you to sign a JAR file as one large object instead of signing every JAR entry individually. This saves up to 10% of the total JAR size. Note: Users must run JRE 7 Update 2 or later to be able to use these JARs. See 7049193 and the section Sign the JAR Files in Packaging (the information in this section also applies to Java SE).
• Caching certificate details in the JNLP file for signed applications: For an application that uses security, a security dialog will present the cached certificates immediately for user approval while downloading the application in the background. An older JRE will ignore this functionality; it will present the certificate information after the application is downloaded. See 7049169 and the section Embed Signing Certificate into Deployment Descriptor in Packaging (the information in this section also applies to Java SE).
• Caching enabled by default: Caching of network content for application code running in Web Start mode is now enabled by default. This allows application improved performance and consistency with applet execution mode. To ensure the latest copy of content is used, the application can use URLConnection.setUseCaches(false) or request header Cache-Control values no-cache/no-store.
• Embedded JNLP support for Web Start: The Deployment Toolkit can use a copy of a JNLP file embedded into a web page to launch an application. This helps to reduce number of network connections needed for the first start of a Web Start application from the browser. See 7052492 and the section Embed Deployment Descriptor into Web Page in Packaging (the information in this section also applies to Java SE).
• Ability to pass secure JVM arguments to the Web Start application from inside the web page using Deployment Toolkit: This helps to avoid JVM relaunch due to JVM configuration mismatch and also helps to pass dynamic parameters from the web page. See 7072364 and the section Platform in Deployment in the Browser (the information in this section also applies to Java SE).
• Improvements for handling content with gzip encoding: The deployment cache will keep application content in compressed form and return it to the application as-is with gzip content-encoding in the HTTP header. This makes behavior more consistent across different execution modes (first launch versus subsequent launch, cache enabled versus cache disabled). See 6575586 for more details.
• Improved support for JNLP applications: JavaFX applications are more cleanly uninstalled; see 7085171 and 7053087. Recognition of JNLP install hints is improved; see 7046670.
• Startup improvements: Startup has been improved for specific scenarios; see 7099086 and 7098160 for details.
• New setting, Insecure JRE versions, in Java Control Panel: If users have a version of Java on their system that is below the security baseline, a warning message is displayed before an application or an applet can be run using that version. You can control this warning message with the Java Control Panel Advanced tab setting, Insecure JRE versions, which will set the property deployment.insecure.jres in the deployment.properties file to one of the following values:

  Value of deployment.insecure.jres property	Value of Insecure JRE versions setting	Description
  NEVER	Do not use insecure JRE versions	Untrusted content will always run with the default JRE.
  PROMPT	Prompt user before using insecure JRE versions	Users will see the new warning dialogs; this is the default value.
  ALWAYS	Allow using insecure JRE versions (not recommended)	Untrusted content will run with the requested JRE without any prompting.

  See Deployment Configuration File and Properties for more information about the deployment.properties file.

Bug Fixes

Java SE 7u2 does not add any fixes for security vulnerabilities beyond those in Java SE 7u1. Users who have Java SE 7u1 have the latest security fixes and do not need to upgrade to this release to be current on security fixes.

Notable Bug Fixes in Java SE 7u2

This list includes some of the nota

Synopsis: The Java 7 compiler used to erroneously accept the diamond operator in array initializer expressions. For example, the following code, which was previously accepted, is now rightly rejected:

  class Foo<X> {}

class Test {
    Foo<String>[] fooArr = new Foo<>[]{ }; //error
}

See 7057297.

Area: Compiler
Synopsis: The Java 7 compiler erroneously accepted the following program due to a bug in the most specific algorithm implementation:

  import java.util.*;

interface A {List<Number> getList();}
interface B {ArrayList getList();}
interface AB extends A, B {}

class Test {
   void test(AB ab) {
      Number n = ab.getList().get(1);
   }
}

This program used to fail in JDK 6. A fix has been provided in Java SE 7u2 to rightly reject this program. See 7062745.

Area: Java Cryptography Extension
Synopsis: Public key certificates containing Elliptic Curve Cryptography (ECC) keys are parsed correctly by the SunPKCS11 JCE security provider on Solaris 11. See 7054637.

Area: hotspot/runtime_logging

Synopsis:Handling large log files produced by long running Java Applications

Three new java command line flags are introduced in this release to handle large log files:

• -XX:+UseGCLogFileRotation:  must be used with -Xloggc:<filename>
• -XX:NumberOfGClogFiles=<number of files>:  must be >=1, default is one
• -XX:GCLogFileSize=<number>M (or K):  default will be set to 512K

See 6941923.

For other bug fixes, see Java SE 7u2 Bug Fixes.

Known Issues

Area: Security

Synopsis: Existing JRE 6 users of signed applications or applets might get SecurityException when upgrading to JRE 7. This issue does not occur on Windows XP with jar files signed by the Maven Jar Tool.

The workaround for client machines is to clear the application from the Java deployment cache using the Java Control Panel. The workaround on the server side, which application publishers could do, is to change the last modified timestamp of the application signed jars. This would force redownload and automatic rebuild of the cache entries on the client side, thus help application users to avoid encountering the error. See 7083682.

Area: Install

Synopsis: In the past, only a deploy stack was installed with the JRE. Now a deploy stack can be delivered either by JavaFX or by the JRE. As the JRE does not understand this, the net result sometimes is a non-functional JRE.

In some cases this can be corrected by uninstalling JavaFX and the JREs, and then re-installing the JRE and re-installing JavaFX. Sometimes this does not work and you have to manually delete a registry key before you are able to get Java working properly again. See 7088173.

Area: Security

Synopsis: Inconsistent security dialog message when a JAR has been blacklisted. Tracing has to be enabled in the console to actually see if a JAR has been blacklisted. See 7112206.