The following sections summarize changes made in the Java SE 8u11 BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.
To determine the version of your JDK software, use the following command:
java -version
Please note that fixes from the prior BPR (8u5 b31) are included in this BPR.
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) |
---|---|
8 | 1.8.0_11 |
7 | 1.7.0_65 |
6 | 1.6.0_81 |
5.0 | 1.5.0_71 |
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.
See jdeps man page and the jdeps Open JDK wiki page.
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.
Entry-Point
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.
maxElementDepth
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.
jdk.xml.maxElementDepth
See 8031541 (not public).
This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.
The following are some of the notable bug fixes in this release:
Area: client-libs/AWT
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.
See 8019274.
BugId | Component | Subcomponent | Summary |
---|---|---|---|
8023990 | client-libs | 2d | Regression: postscript size increase from 6u18 |
8041572 | client-libs | java.awt | [macosx] huge native memory leak in AWTWindow.m |
8041987 | client-libs | java.awt | [macosx] setDisplayMode crashes |
8019990 | client-libs | java.awt:i18n | IM candidate window appears on the South-East corner of the display |
8035897 | core-libs | java.net | Better memory allocation for file descriptors greater than 1024 on macosx |
8043012 | core-libs | java.util:i18n | (tz) Support tzdata2014c |
8019274 | deploy | RMI thread can no longer call out to AWT thread for webstart app | |
8032781 | deploy | deployment_toolkit | Run rule not working in case of html applet |
8030636 | deploy | plugin | Accessibility class in jar on -xbootclasspath/a is not loaded by jvm |
8031996 | deploy | plugin | Java.Lang.Reflect.InvocationTargetException When Cache Has Disabled |
8032206 | deploy | plugin | Applet with jnlp.Packenabled=True And jnlp.versionEnabled=True Fails |
8034230 | deploy | plugin | Applet caller check should not compare URLs |
8035449 | deploy | plugin | security prompt is shown twice when 'Do not show' checkbox is checked |
8041339 | deploy | webstart | JNLP with java-vm-args whose length exceeded 512 chars failed to get loaded with CouldNotLoadArgumentException |
8035613 | xml | jaxb | With active Securitymanager JAXBContext.newInstance fails |
Area: xml/jax-ws
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 javax.mail
API:
MailcapCommandMap mailMap = (MailcapCommandMap)
CommandMap.getDefaultCommandMap();
mailMap.addMailcap("multipart/mixed;;x-java-content-
handler=com.sun.mail.handlers.multipart_mixed");
See 8043129.