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.8.0_60-b27 (where "b" means "build"), except for OS X, where the version string is 1.8.0_60-b28. The version number is 8u60.
This update release contains several enhancements and changes including the following:
JDK 8u60 contains IANA time zone data version 2015e. 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 8u60 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 8u60) will expire with the release of the next critical patch update scheduled for October 20, 2015.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u60) on November 20, 2015. 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.
This release includes Java Development Kit for ARM Release 8u60 (JDK 8u60 for ARM).
For ARM device support information, see Java SE Development Kit Downloads page.
For system requirements, installation instructions and troubleshooting tips, see Installation Instructions page.
Limitation: Native Memory Tracking support is limited in JDK for ARM. The java command line option
XX:NativeMemoryTracking=detail is not supported for ARM targets (an error message is displayed to user). Instead, use the following option:
New "Use roaming profile" option added in Java Control Panel (Windows only)
New option "Use roaming profile" added in JCP (Windows only).
1. The option is set when file <user_home>
2. Setting this option in JCP results in deployment.properties file from LocalLow being copied to the Roaming folder.
3. Clearing this option results in the
deployment.properties file being moved from the Roaming folder to the LocalLow folder.
When the option is set, the following data is stored in the roaming profile:
2. local application properties
3. security baselines
4. blacklisted certs
5. blacklisted jars
6. user certs stores
7. exception site list
The rest of the cache ( the cache without LAP), temp and log folders are always stored in LocalLow regardless of the roaming profile settings.
JDK-8062830 (not public)
Different bytecode between JDK8u45 and JDK8u60
Fixing JDK-8064857 has provoked a benign, actually beneficial, side effect in
javac's code generation. The mentioned fix has improved the information
javac has about aliveness of local variables and thus jump chains have richer information allowing the compiler to generate direct jumps to the final destination when in the past a chain of intermediate jumps were generated.
IBM1166 character set now available
This release adds IBM1166 character set. It provides support for cyrillic multilingual with euro for Kazakhstan. Aliases for this new character set include
Allow use of TransmitFile on Microsoft Windows
Applications running on server editions of Microsoft Windows that make heavy use of
java.nio.channels.FileChannel.transferTo may see performance improvements if the implementation uses
TransmitFile makes use of the Windows cache manager to provide high-performance file data transfer over sockets. The system property
jdk.nio.enableFastFileTransfer controls whether the JDK uses
TransmitFile on Microsoft Windows. It is disabled by default but can be enabled by setting the system property on the command line with
Allow use of SIO_LOOPBACK_FAST_PATH on Microsoft Windows
Applications running on server editions of Microsoft Windows that make heavy use of loopback connections may see latency and performance improvements if SIO_LOOPBACK_FAST_PATH is enabled. The system property
jdk.net.useFastTcpLoopback controls whether the JDK enables SIO_LOOPBACK_FAST_PATH on Microsoft Windows. It is disabled by default but can be enabled by setting the system property on the command line with
G1 now collects unreachable Humongous objects during young collections
G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references.
Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled.
Documentation Updates due to Nashorn Enhancements
JDK 8u60 includes new enhancements to Nashorn. As a result the following documentation changes should be read in conjunction with the current Nashorn documentation:
Java.asJSONCompatible(obj) function, where
obj is the root of your JSON object tree.
The caution mentioned at the end of Mapping Data Types section, is no longer applicable.
java.lang.String when exposed externally.
The statement in the section Mapping Data Types, that mentions "For example, arrays must be explicitly converted,........." is not correct.
Arrays are automatically converted to Java array types, such as
java.util.Deque and so on.
Changes in Deployment Rule Set v1.2
JDK 8u60 implements Deployment Rule Set (DRS) 1.2, which includes the following changes:
"checksum" element as sub element of
"id" which can allow unsigned jars to be identified by the SHA-256 checksum of the uncompressed form of a jar:
"checksum"element will match only unsigned jars, and the given hash will be compared only against the uncompressed form of the jar.
"checksum"element (similar to
"certificate"element) has two arguments
"algorithm", however, unlike
"certificate"element, the only supported value for
"algorithm"is "SHA-256". Any other value provided will be ignored.
"message" element to apply to all rule types, where previously it only applied to a block rule:
"customer" blocks in the Java Console, trace files, and Java Usage Tracker records.
"customer"elements could be included (with any sub-elements) in the
ruleset.xmlfile. This element and all its sub elements are ignored. In DRS 1.2, the elements are still functionally ignored. However:
"customer"blocks will be echoed to the Java Console and deployment trace file (if Console and Tracing are enabled).
"customer"records included within that rule will be added to the Java Usage Tracker (JUT) record (if JUT is enabled).
As a result of the above changes, the DTD for DRS 1.2 is as follows:
<!ELEMENT ruleset (rule*)> <!ATTLIST ruleset href CDATA #IMPLIED> <!ATTLIST ruleset version CDATA #REQUIRED> <!ELEMENT rule (id, action)> <!ELEMENT id (certificate?, checksum?) > <!ATTLIST id title CDATA #IMPLIED> <!ATTLIST id location CDATA #IMPLIED> <!ELEMENT certificate EMPTY> <!ATTLIST certificate algorithm CDATA #IMPLIED> <!ATTLIST certificate hash CDATA #REQUIRED> <!ELEMENT checksum EMPTY> <!ATTLIST checksum algorithm CDATA #IMPLIED> <!ATTLIST checksum hash CDATA #REQUIRED> <!ELEMENT action (message?)> <!ATTLIST action permission (run | block | default) #REQUIRED> <!ATTLIST action version CDATA #IMPLIED> <!ATTLIST action force (true|false) "false"> <!ELEMENT message (#PCDATA)> <!ATTLIST message locale CDATA #IMPLIED>
For a list of bug fixes included in this release, see JDK 8u60 Bug Fixes page.
The following are some of the notable bug fixes included in JDK 8u60 release:
Synopsis: Nondeterministic wrong answer on arithmetic corrected
When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed.
Synopsis: dns_lookup_realm should be false by default
The dns_lookup_realm setting in
Kerberos' krb5.conf file is by default
Synopsis: Disable RC4 cipher suites
RC4-based TLS ciphersuites (e.g. TLS_RSA_WITH_RC4_128_SHA) are now considered compromised and should no longer be used (see RFC 7465). Accordingly, RC4-based TLS ciphersuites have been deactivated by default in the Oracle JSSE implementation by adding "RC4" to "jdk.tls.disabledAlgorithms" security property, and by removing them from the default enabled ciphersuites list. These cipher suites can be reactivated by removing "RC4" form "jdk.tls.disabledAlgorithms" security property in the
java.security file or by dynamically calling Security.setProperty(), and also readding them to the enabled ciphersuite list using the SSLSocket/SSLEngine.setEnabledCipherSuites() methods.
You can also use the
-Djava.security.properties command line option to override the
jdk.tls.disabledAlgorithms security property. For example:
java -Djava.security.properties=my.java.security ...
my.java.security is a file containing the property without RC4:
Even with this option set from commandline, the RC4 based ciphersuites need to be re-added to the enabled ciphersuite list by using the
Synopsis: Support keystore type detection for JKS and PKCS12 keystores
Keystore Compatibility Mode:
To aid interoperability, the Java keystore type JKS now supports keystore compatibility mode by default. This mode enables JKS keystores to access both JKS and PKCS12 file formats. To disable keystore compatibility mode set the Security property
keystore.type.compat to the string value
Synopsis: Deprecate Unsafe monitor methods in JDK 8u release
sun.misc.Unsafe are marked as deprecated in JDK 8u60 and will be removed in a future release. These methods are not used within the JDK itself and are very rarely used outside of the JDK.
Synopsis: Extract JFR recording from the core file using SA
DumpJFR is a Serviceability Agent based tool that can be used to extract Java Flight Recorder(JFR) data from the core files and live Hotspot processes. DumpJFR can be used in one of the following methods:
java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>
java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
DumpJFR tool dumps the JFR data to a file called recording.jfr in the current working folder. 8065301(not public).
Synopsis: Local variables named 'enum' lead to spurious compiler crashes
javac parser is incorrectly parsing local variables with name 'enum'; this results in spurious failures when a program containing such local variables is compiled with a 'source' flag corresponding to a release in which the enum construct is not available (such as '-source 1.4').
Area: auto-update (OS X 10.11+ only)
Synopsis: Auto-update error when auto-updating to earlier versions
A change in OS X 10.11 caused the auto-update mechanism to fail when a system running OS X 10.11 is auto-updated from versions 8u40 through 8u60 build 27, inclusive. This issue was addressed in 8u60 build 28 and later. The issue only appears when a JRE release between 8u40 and 8u60 b27 has been installed on Mac OS X 10.11 and is then used to trigger an auto-update sequence. Impacted machines would appear to go through the update flow but at the end of the process the newer JRE would not be installed, the older JRE would remain, and therefore the auto-update mechanism would continue prompting the user to update. Workaround: Manually install a JRE version 8u60 b28 or higher into the affected system.