• Skip to content
• Accessibility Policy

• Update Release Notes Index
• JDK Documentation

Changes in 1.6.0_14 (6u14)

The full internal version number for this update release is 1.6.0_14-b08 (where "b" means "build"). The external version number is 6u14.

OlsonData 2009g

6u14 contains Olson time zone data version 2009g. For more information, refer toTimezone Data Versions in the JRE Software .

Security Baseline

6u14 specifies the following security baselines for use with Java Plug-in technology:

On October 30, 2008, Java SE 1.4.2 reached its end of service life with the release of 1.4.2_19. Future revisions of Java SE 1.4.2 (1.4.2_20 and above) include the Access Only option and are available to Java SE for Business subscribers.

For more information about the security baseline, seeDeploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer .

Additional Supported System Configurations

For 6u14, support has been added for the following system configurations:

• Windows Server 2008 SP2
• Windows Vista with SP2

Refer to theSupported System Configurations page.

Service Tag Support

Service Tag support on Solaris and Linux was added in version 1.6.0_04. JRE 1.6.0_14 extends Service Tag support to Windows. If Service Tag software has been installed on a system where JRE 1.6.0_14 is being installed, a unique service tag is automatically created for that particular JRE instance. There is no change in the JDK/JRE installation instruction, and there is no change in the Java runtime.

Blacklist Jar Feature

Support for blacklisting signed jar files has been added to 6u14. A blacklist is a list of signed jars that contain serious security vulnerabilities that can be exploited by untrusted applets or applications. A system-wide blacklist will be distributed with each JRE release. Java Plugin and Web Start will consult this blacklist and refuse to load any class or resource contained in a jar file that's on the blacklist. By default, blacklist checking is enabled. Thedeployment.security.blacklist.check deployment configuration property can be used to toggle this behavior.

The blacklist entries are the union of the blacklist files pointed to by thedeployment.system.security.blacklist anddeployment.user.security.blacklist properties. By default,deployment.system.security.blacklist points to theblacklist file in thejre/lib/security directory, anddeployment.user.security.blacklist points to a blacklist file that contains additional entries added by a user.

The blacklist is a text file with the following format:

Each jar file on the blacklist is identified by thex-Digest-Manifest attribute wherex is the name of theMessageDigest algorithm, and the value is the base64 encoded hash value of the Manifest. Comments are denoted by lines starting with the # (number) symbol.

Here is an example:

# Buggy Utilities, version 1.0SHA1-Digest-Manifest : QONXbQg+EtNOguIOAgpUUOadhv8=# Malware Inc., version 99.99SHA-256-Digest-Manifest : SewaudBCZ3iXt1KX0BeFHpQiiM1xYLtvLw3Ow2RJfcs=

Java HotSpot VM 14.0

6u14 includes version 14.0 of the Java HotSpot Virtual Machine, which provides improved reliability, serviceability and performance.

Contributing to increased performance in this release are numerous enhancements to HotSpot's optimizing compiler, more efficient SoftReference processing and improvements to Parallel Compacting garbage collection. Optionally available are two new features -escape analysis andcompressed object pointers. A preliminary version of the newGarbage First (G1) garbage collector is also included.

• Optimization Using Escape Analysis

  The-XX:+DoEscapeAnalysis option directs HotSpot to look for objects that are created and referenced by a single thread within the scope of a method compilation. Allocation is omitted for such non-escaping objects, and their fields are treated as local variables, often residing in machine registers. Synchronization on non-escaping objects is also elided.

• Compressed Object Pointers

  The-XX:+UseCompressedOops option can improve performance of the 64-bit JRE when the Java object heap is less than 32 gigabytes in size. In this case, HotSpot compresses object references to 32 bits, reducing the amount of data that it must process.

• Garbage First (G1) Garbage Collector

  Garbage First, or G1, is a low pause, server style collector. G1's primary advantages over the Concurrent Mark-Sweep (CMS) collector include incremental compaction, better predictability and ease of use.

  G1 is available as early access in this release, please try it and give us feedback. Usage in production settings without aJava SE for Business support contract is not recommended.

  To try G1, specify these command line options:

  -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

  In addition, the following options can be used to affect G1's behaviour:

  • To set the max GC pause time goal in milliseconds that G1 will attempt to meet:-XX:MaxGCPauseMillis=<X>
  • To set the time interval over which GC pauses totaling up to MaxGCPauseMillis may take place:-XX:GCPauseIntervalMillis=<X>

Improvement TreeMap Iteration

6u14 includes an experimental implementation ofjava.util.TreeMap that can improve the performance of applications that iterate over TreeMaps very frequently. This implementation is used when running with the-XX:+AggressiveOpts option.

JAX WS 2.1.6 and JAXB 2.1.10

JAX-WS 2.1.6 and JAXB 2.1.10 are integrated into JDK 6u14.

Refer also toCR 6803688.

JavaDB 10.4.2.1

6u14 contains the new 10.4.2.1 version of Java DB.

Java VisualVM Updates

6u14 contains the following updates to Java VisualVM:

• CPU usage and GC activity graph in the Monitor tab
• Table view in the Threads tab
• Command line options: --openpid, --openjmx, --openfile
• Compare Memory Snapshots action in the context menu
• Copy To Clipboard / Save To File buttons in the About dialog
• Monitoring IBM JVM via JMX connection
• Based on NetBeans Platform 6.5 and NetBeans Profiler 6.5
• Faster computation of references, and improved readability of path to GC root in HeapWalker
• Improved integration of the Visual GC tool

Click for a list ofJava VisualVM bug fixes related to this release.

Debug Issue

Java ™ Virtual Machine Tool Interface (JVM TI) breakpoints are reliable only when either the Parallel Scavenge garbage collector (-XX:+UseParallelGC) or the Parallel Compacting garbage collector (-XX:+UseParallelOldGC) is used.

When other collectors are used, breakpoints may stop functioning, and JVM TI object tags may become unusable after a full GC operation is performed. Java ™ Debug Interface (JDI) ThreadReferences have an embedded thread ID that depends on JVM TI object tags, thus the embedded thread ID may change unexpectedly. This may cause confusion in thread based JDI events.

Note that the Serial garbage collector (-XX:+UseSerialGC) is vulnerable to this problem and is selected by default on some platforms. The work around is to explicitly select the Parallel Scavenge collector using the command line option-XX:+UseParallelGC.

(Refer to6862295.)

Issue with JDK Silent Installation

Prior to 6u14, the JDK installer was never fully supported silently. One of the side effects of silent JDK installation is that it does not install the public JRE. It used to cache/install a jre.msi file. Apparently some users have been using the jre.msi without our documentation or approval. As of 6u14, we no longer cache the file.

As a workaround to the JDK not installing the public JRE when in silent mode, we recommend also bundling up and launching the stand-alone JRE installer from theJSC download site.

We intend to provide full silent JDK installer support in 6u15, under the following CR:6845077 - silent JDK should install JRE/Java DB silently

Possible Issue for Java Web Start Applications

In 6u14 Java Web Start, if you specify an insecure Java system property in a sandbox JNLP file, Java Web Start fails to launch and notifies that JARs in the sandbox JNLP file are not signed.

A workaround is to remove the insecure property (which was ignored by all previous versions of Java Web Start). Refer to CR6845294

Bug Fixes

This feature release does not contain any new fixes for security vulnerabilities to its previous release, Java SE 6 Update 13. Users who have Java SE 6 Update 13 have the latest security fixes and do not need to upgrade to this release to be current on security fixes.

Bug fixes are listed in the following table.

Java VisualVM Specific Bug Fixes