Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
The full version string for this update release is 1.7.0_45-b18 (where "b" means "build"). The version number is 7u45.
JDK 7u45 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 7u45 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 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 7u45) will expire with the release of the next critical patch update, scheduled for January 14, 2014.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 7u45) on February 14, 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.
This update release includes a blacklist entry for a standalone JavaFX installer.
JavaFX is now part of JDK. JDK 7u45 release includes JavaFX version 2.2.45.
A JDK for Linux ARM is also available in this release.
Starting with 7u45, application developers can specify new JAR manifest file attributes:
Application-Name: This attribute provides a secure title for your RIA.
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.
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.
Starting from JDK 7u45, the following new processing limits are added to the JAXP
java.util.TimeZone.setDefault(TimeZone) method has been changed to throw a
SecurityException if the method is called by any code with which the security manager's
checkPermission 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 the
java.util.TimeZone class is loaded and initialized.
This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.
You can work around this using one of the following approaches:
When specifying the codebase, using the
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 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 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
Caller-Allowable-Codebase may be ignored when used with
If a trusted, signed JAR file is using the
Caller-Allowable-Codebase manifest attribute along with
Trusted-Library then the
Trusted-Library manifest entry.
Synopsis: Applet could fail to load by throwing NPE if pack compression is used with deployment caching disabled.
If a JAR file is using pack compression with manifest entries
Caller-Allowable-Codebase while deployment caching is disabled, then:
Permissionsmanifest entry will be ignored. (This can be seen from the fact that yellow warning is there on security dialog even though the
Permissionsattribute is there.) This only happens if
Caller-Allowable-Codebaseattribute is present along with the
Caller-Allowable-Codebaseattribute will cause the applet to fail to load by throwing a
If you want to use pack compression with the
Caller-Allowable-Codebase attribute, there are two possible workarounds:
jnlp.packEnabled=truewhile deploying the applets using
premissionsproperty. Instead use the
ContentTypeservlet for serving the pack files.
Synopsis: Non-JNLP trusted applet fails to load using the
Local trusted applets that do not deploy using a JNLP file will fail to load by throwing a
java.lang.NullPointerException. You can work around this issue by using one of the following methods:
Synopsis: JNLP applet fails to load if using JNLP versioning.
Due to this bug, if you are using the
jnlp.versionEnabled property for JAR versioning in your browser applet, your applet might not start. Also users might see a yellow warning about a missing
Permissions attribute in the following two scenarios:
jnlp.versionEnabledproperty is set to
falseinside the JNLP file and the version is defined against the main JAR file.
The workaround is to either not use versioning via
jnlp.versionEnabled, or to use the
JNLPDownloadServlet servlet for version support instead.
Synopsis: Using RMI from a restricted environment may cause a
If an application uses RMI and runs in a restricted environment (ie. Java Plugin, Java Web Start), it may not work. In particular, if you run a UI from an RMI callback, a
NullPointerException is likely to be thrown.