The full version string for this update release is 1.7.0_40-b43 (where "b" means "build"). The version number is 7u40.
This update release contains several enhancements and changes including the following:
JDK 7u40 contains Olson time zone data version 2013d. 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 7u40 are specified in the following table:
|JRE Family Version||JRE Security Baseline
(Full Version String)
For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.
The expiration date for JRE 7u40 is 12/10/2013. After this date, Java will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
Java Mission Control (JMC) is a commercial feature available for java users with a commercial License.
JDK 7u40 includes the first release of Java Mission Control (JMC) that is bundled with the Hotspot JVM. For more information, see JMC Release Notes.
JavaFX is now part of JDK. JDK 7u40 release includes JavaFX version 2.2.40.
For a list of bug fixes included this release, see JavaFX Bug Fixes page.
For a list of known JavaFX issues, see Known Issues.
Serviceability Agent support: Serviceability Agent (SA) is now supported in JDK for ARM.
ARM hard float support: 7u40 adds ARM Hard-Float ABI (ARMHF) support in addition to existing ARM Soft-Float ABI support. The ARMHF bundle is labeled
A target system must provide access to
ld-linux-armhf.so.3 dynamic linker/loader through a hard or symbolic link.
Note: The Server JIT compiler (C2) requires ARMv7.
Retina screens will now display content correctly. Previously rendering had been blurry. See 8000629.
Deployment rule set allows a desktop administrator to control the level of Java client compatibility and default prompts across an organization.
For a summary of this feature, see Deployment Rule Set documentation.
Starting from 7u40, a new deployment property
deployment.expiration.check.enabled is available. This property can be used to disable the "JRE out of date" warning.
When the installed JRE (7u10 or later), falls below the security baseline or passes it's built-in expiration date, an additional warning is shown to users to update their installed JRE to the latest version. For businesses that manage the update process centrally, users attempting to update their JRE individually, may cause problems.
To suppress this specific warning message, add the following entry in the deployment properties file:
For more information, see Deployment Configuration File and Properties.
New warnings are added in the dialogs for Unsigned and Self-Signed applications.
From the dialogs for Unsigned and Self-Signed applets, "Remember this decision" option has been removed. In addition, the previously remembered decisions for self-signed and unsigned applets will be ignored.
For more information, see Security Dialogs.
Beginning with JDK 7u40, an applet's
getDocumentBase() method will return NULL when the applet is running from the local file system.
If applet needs to load resource, here are the options:
ClassLoader getResoruceAsStreamdirectly, without needing the codebase information.
user.homejava system property, provided their applet has
JDK 7u40 release contains Java API for XML Processing (JAXP) 1.5, which adds the ability to restrict the set of network protocols that may be used to fetch external resources. For more information, see JEP 185: JAXP 1.5: Restrict Fetching of External Resources.
Starting from 7u40, the use of x.509 certificates with RSA keys less than 1024 bits in length is restricted. This restriction is applied via the Java Security property,
jdk.certpath.disabledAlgorithms. The default value of
jdk.certpath.disabledAlgorithms is now as follows:
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
In order to avoid the compatibility issue, users who use X.509 certificates with RSA keys less than 1024 bits, are recommended to update their certificates with stronger keys. As a workaround, at their own risk, users can adjust the key size to permit smaller key sizes through the security property
For a list of bug fixes included in this release, see JDK 7u40 Bug Fixes page.
The following are some of the known issues in JDK 7u40.
Synopsis: Aborting the update after clicking "Update" on the "Java is insecure" warning message forwards all applets to java.com/download.
When an older JRE is installed on the system, launching a web page with an applet prompts the user with "Java is insecure" message. If the user clicks on the "Update" button on the message but later aborts the update process, user is automatically redirected to http://java.com/download page.
This is not the expected behavior. The issue is fixed in JDK 7u40 release.
Synopsis: Expired (but otherwise valid) certificate are not blocked at VeryHigh Security Level.
The issue is fixed in JDK 7u40 release.
The following are some of the notable bug fixes in JDK 7u40 release:
Synopsis: On Mac OS X update from the Java Control Panel on a system with JRE 7u25 fails to find JRE 7u40.
Mac OS X users with JRE version 7u25 installed that try to update using the Java Control Panel are told that they have the current version installed rather than being offered the option to install 7u40.
For more details see: JDK-8024640.
Workaround: Manually download JRE 7u40 for Mac OS X from java.com or OTN and install it.
Synopsis: Locking behavior for JCP is not clear for OCSP/CRL (Adding deployment.security.validation.crl.locked property in config file does not reflect in JCP. )
Adding deployment.security.validation.crl.locked in config file does not seem to disable (gray out) Revocation Check property in Java Control Panel (JCP).
For example, a deployment property file
c:\Windows\Sun\Java\Deployment\deployment.config file is created with the following content:
deployment.security.mixcode=DISABLE deployment.security.mixcode.locked deployment.security.validation.crl=true deployment.security.validation.crl.locked
When the JCP is displayed, the mix code section will be disabled (all grayed out), but the certificate revocation section still active/changeable.
Workaround: The regression is only in display and the locking is working.
java/awt/Frame/HugeFrame/HugeFrame.java sometimes fails on Mac OS X.
Creating huge frames in Mac OS X on some hardware does not work. The issue is known to be reproducible with Intel HD 4000 video card for frames with more than 10000 pixel size. There is no known workaround.
Synopsis: New minimum young generation size is not properly checked by the JVM.
In JDK 7u40, the minimum size of the young generation for the parallel garbage collector was increased from 192 KB to 768 KB in a 32-bit JVM, and to 1536 KB in a 64-bit JVM. This new minimum size is not properly checked by the JVM. If a young generation size that is smaller than the new minimum is specified on the command line, it can result in either a crash or degraded performance.
The young generation size is set by the options
-XX:NewSize=<N> and -
XX:MaxNewSize=<N>, or by the option
-Xmn<N> (the latter option is equivalent to setting both NewSize and MaxNewSize to
<N>). If the above options are not used, then the young generation size is computed as a fraction of the maximum heap size.
Workaround: Use a young generation size that is at least 768 KB (for 32-bit JVM) or 1536 KB (for 64-bit JVM).
Synopsis: Irregular crash or corrupt term vectors in the Lucene libraries.
The JVM can crash or produce a corrupt term vector in a narrow corner case in the Lucene library; these types of crashes are caused by a corrupted array index value which sometimes is not initialized properly. The effect of this is an array index value that points to an incorrect element of the array.
For more details see: JDK-8024830.
Workaround: Use the flag -XX:- UseSuperWord at the JVM command line.
Synopsis: Java causes MacOSX to crash with kernel panic
The JVM could cause kernel panic on MacOSX v10.8.1 and v10.8.2. It is an MacOSX issue which is not reproduced on v10.8.3. User needs to upgrade to the latest MacOSX 10.8.x version to avoid this issue.
Synopsis: Local applet could not be launched with Firefox 23
This is a Firefox bug and a fix will be provided in a future release. This regression is introduced due to a fix against issues related to same-origin policy under Firefox. For more details, see https://bugzilla.mozilla.org/show_bug.cgi?id=902375.
Workaround: To work with Firefox 23, under Firefox preferences, set the property
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.
Workaround: Use the java_version applet parameter or the version attribute of the Java element in JNLP file instead.
Synopsis: Certificate-based DRS rule does not work when main JAR file is in nested resource block
The certificate-based Deployment Rule Set rule does not work properly for JNLP applications when the main JNLP file has no JAR files, or all JAR files are in nested resource blocks nested in <java> or <j2se> elements.
Workaround: Reorganize the application to avoid this scenario.
Synopsis: Packager for Mac OS generates invalid ICNS icon.
After an application is packaged with the native Mac OS packager, the
.app bundle contains an invalid ICNS icon. When developers try to submit this application to Mac App Store, the Application Loader fails with the error reporting about an invalid ICNS icon.
To overcome the issue, perform the following steps:
Change dir into generated bundles directory (
./dist/bundles). There you can find
Write entitlements for your application. All programs, delivered by Mac App Store, are started within sandbox, so you have to describe needs of your application in some specific format, described on Apple official sites: some template you can find here. Let this file be named MyApp.entitlements.
For some packager bug, we had to remake icon in
$ cd ./dist/bundles/MyApp.app/Resources $ iconutil -c iconset MyApp.icns $ rm -f MyApp.icns $ iconutil -c icns MyApp.iconset $ rm -rf MyApp.iconset $ cd ../../../../
codesign -f -s "3rd Party Mac Developer Application: <Your name>"
--entitlements MyApp.entitlements MyApp.app.
Sign all sub-libraries and jars:
find MyApp.app -name "*.jar" -or -name "*.dylib" | xargs
codesign -f -s "3rd Party Mac Developer Application: <Your name>"
Build signed .pkg:
$ productbuild --component MyApp.app /Applications
--sign "3rd Party Mac Developer Installer: <Your name>"
--product MyApp.app/Contents/Info.plist MyApp.pkg
Don't be confused by different certificated: there must be at least two certificates: Application certificate and Submission/Installer certificates.
For more information see, JavaFX issue RT-31417.
Synopsis: The WebView component doesn't support HiDPI rendering.
See JavaFX issue RT-31729.
Synopsis: The HiDPI support cannot be enabled inside a LoDPI browser.
See JavaFX issue RT-30912.
Synopsis: Point and Spot lights of the Lighting effect are not affected by coordinate scaling.
The coordinates of the lighting sources are not adjusted for the coordinate transform of a node and are actually relative to its bounding box, which makes positioning the lights properly for an arbitrary node tricky.
For more information, see JavaFX issue RT-31849.