The full version string for this update release is 1.8.0_11-b12 (where "b" means "build"). The version number is 8u11.
This update release contains the following enhancements and changes:
JDK 8u11 contains IANA time zone data version 2014c. 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 8u11 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 8u11) will expire with the release of the next critical patch update scheduled for October 14, 2014.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u11) on November 15, 2014. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
A new command-line tool, Java Dependency Analysis Tool (jdeps), is now available that can be used by developers to understand the static dependencies of their applications and libraries. It also provides an
-jdkinternals option to find dependencies of any JDK internal APIs that are unsupported and private to JDK implementation.
Currently, to disable sponsor offers at the time of installation, the user can deselect the option during installation or can pass
SPONSORS=0 as a command line option.
In this release, a new Java Control Panel(JCP) option to disable sponsors is available. To use this option, go to JCP's "Advanced" tab, and check or uncheck "Suppress sponsor offers when updating Java".
This option is applicable to 32 and 64 bit Windows operating systems.
From this release, a new JAR file attribute,
Entry-Point is available. The Entry-Point attribute is used to identify the classes that are allowed to be used as 'entry points' to the RIA. Identifying the entry points helps to prevent unauthorized code from being run when a JAR file has more than one class with a main() method, multiple Applet classes, or multiple JavaFX Application classes. Set this attribute to the fully qualified class name that can be used as the entry point for the RIA. To specify more than one class, separate the classes by a space, for example:
Entry-Point: apps.test.TestUI apps.test.TestCLI
If the JAR manifest is signed and the main-class or applet-class entry point specified in the JNLP file or application descriptor differs from the class specified for the Entry-Point attribute, then the RIA is blocked. If the Entry-Point attribute is not present, any class with a main() method, or any Applet or JavaFX Application class in the JAR file can be used to start the RIA.
A new property,
maxElementDepth, is added to provide applications the ability to set limit on maximum element depth in an xml file that they parse. This may be helpful for applications that may use too much resources when processing an xml file with excessive element depth.
For more details, see Processing Limits from JAXP tutorial trail.
See 8031541 (not public).
This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.
For a list of bug fixes included in this release, see JDK 8u11 Bug Fixes page.
The following are some of the notable bug fixes in this release:
Synopsis: Using RMI from a restricted environment may cause a NullPointerException.
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.
Synopsis: JAF initialization in SAAJ clashing with the one in javax.mail
After initialization of SAAJ components, the
javax.mail library may fail to work under certain circumstances, which in turn could break the javax.mail's JAF setup.
A possible workaround is to re-add the javax.mail handler before using
MailcapCommandMap mailMap = (MailcapCommandMap) CommandMap.getDefaultCommandMap();