The new <update> element with it's "policy" and "check" attributes is now supported.  The update element describes the applications preferences for how Java Web Start should check for updates on the web, and what to do when it is known before launching that an update is available.
In the previous versions of Java Web Start the <offline-allowed> element was overloaded to mean two things.  First, it meant that the application was allowed to run in "offline" mode. (An application can be run in offline mode either from the command line by adding the "-offline" argument, or from the Cache Viewer.)  Second, it meant that attempts to check for update before launching an application (when not run in offline mode) could time out.  When a check for update times out, the application would be launched from the cache wile the update check continued in the background.
With the advent of the <update> element and it's check attribute in 6.0, the <offline-allowed> element no longer has this second meaning.  The default values:  <update check="timeout"/>.  which is the same behavior as previous versions where <offline-allowed> was specified.  For the behavior that previously used whenever <offline-allowed> was omitted, you need to specify <update check="always"/>. A third value <update check="background"/> can be specified to always immediately launch from the cache while spawning a check for update in the background.    The second attribute, "policy", is used to determine what to do when it is known before starting the application that there is an update available.  You can either always get the update, or prompt the user. The policy attribute values can be either "always" (this is default) , "prompt-update" or "prompt-run".

In the previous versions, the URLs passed as arguments to all of the APIs were restricted to be URLs to resources listed in the jnlp file(s) of the running application.  This restriction is changed such that there are no restrictions for signed and trusted code, and the restriction on untrusted code is not that it be listed in the jnlp file(s), but only that it be from the same codebase.
Further, URLs to jnlp file(s) themselves are allowed, so that calling DownloadService.removeResource() can now be used to remove a whole application from the cache, and DownloadService.loadResource() can be used to import an application.
One effect of this change is that now resources not listed in any jnlp file can now be used in an application.  For example, after determining the locale is set to en_xx, an application can then load resources_en_xx.jar using the DownloadService, without listing all the available resource jars in the jnlp file. (Allowing you to dynamically add support for more locales without changing the jnlp file).

Another significant specification change is a clarification in the definition of the sandbox, that it is only the default sandbox, and that the implementation is free to prompt the user to allow actions that wouldn't be allowed by the sandbox.  You already saw in 1.5.0 that this was done for printing, so that just by using the normal printing api in awt, you could expand the sandbox to allow the application to access the printer (if the user agreed).  In 6.0 this is also done for socket connections, so that if an untrusted application attempts to connect to a url, the user can be prompted to allow the connection. 

For jnlp files that will only be used with Java Web Start version 6.0 or later, the <java> element can be used to replace the <j2se> tag.  (This is mainly because the Java Platform Standard Edition is no longer called j2se.)  For backward compatibility, the <j2se> tag will continue to work.  The <java> element will be identical to the <j2se> element..

When creating file extension and mime type associations with you Java Web Start application, you can now specify a separate icon to be used for each association (as opposed to using the default icon for the application).  You can also now specify a description.

The JNLPClassLoader was rewritten to extend URLClassLoader.  This gives several powerful advantages. 
First, Jar Indexing is now fully supported.  If you have several jar files, and create a jar index in the main jar file that indexes all the jar files, you can then mark each additional jar as lazy, and it will not be downloaded until and unless a resource or class in it is referenced.  This makes the old part and package elements unnecessary for insuring that lazy jars are not downloaded prematurely.
Second, Since the JNLPClassLoader now extends URLClassLoader, an Application can call getURLs() to get a list of the jar elements that are listed in the jnlp files (or have been downloaded using the DownloadService API, even if not listed in any jnlp file, see above).
Finally, The URL returned for calls to ClassLoader.getResource() is now the proper JAR URL of the item on the net.  In previous versions, this URL returned was a jar url of the file url of the item in the cache.  By extending URLClassLoader, the cached location (if it exists) is meaningless, and it allows Java Web Start to operate without caching.

Java Web Start now supports two new icon formats, ".png", and ".ico".  This allows you to specify an icon that will not need to be translated into a different format depending on it's use.  You can also now specify kind="shortcut", and Java Web Start will now honor the width and height hints.  This means if you specify:
<icon kind="shortcut" href="menushortcut.ico" width="16" height="16"/>
<icon kind="shortcut" href="desktopshortcut.ico" width="32" height="32"/>
you can specify a separate image for any desktop and menu shortcut created.  (note: for desktop shortcuts, Java Web Start will use the icon whose size is closer to 32X32, and for menu shortcuts Java Web Start will use the icon whose size is closer to 16X16 )

The Windows Add/Remove program entries for Java Web Start applications will now include the publisher, publisher websight,  install date, and application icon from the information block of the jnlp file.

Desktop shortcuts created by Java Web Start will now use the <description> element in the jnlp file to create a tooltip describing the application.

The JnlpDownloadServlet now contains both a $$hostname  and a $$sight macro.  The $$hostname macro is expanded to contain  the host name.  The $$site macro is expanded to contain the web site address without the WAR context portion.

See the developers guide for the current list of safe properties and vm args.

All of the dialogs and screens shown by Java Web Start and Java Plug-in have been redesigned with help from the User Experience team to be more user friendly, intuitive, and accessible.

The entire caching mechanism and download engine has been redesigned and consolidated between Java Web Start and Java Plug-in. 
This brings several new features to Java Web Start, previously available only in Java Plug-in and vise versa.

• Caching can now be disabled entirely via the Java Control Panel.
• The cache max size set in the JCP is now honored in Java Web Start, and a cleanup thread may be started by Java Web Start to removed LRU items from the cache when it is approaching the max size set by the user.
• The <no-cache> directive is now honored.  If a downloaded resource contains the no-cache directive, it will not be put in the cache.
• The expiration-date will be honored.  If a downloaded resource contains an expiration date, it will not be used after that date.

note: The format of the cache is completely changed and should never be assumed.  Any existing code that assumed the previous format of the cache, for either Java Web Start or Java Plug-in will no longer work.  Existing applications in the Java Web Start cache will be upgraded and converted to the new cache format the first time you run a Java Web Start application, or if you launch the cache viewer using "javaws -viewer".  Likewise the system cache will be upgraded and converted to the new format the first time you launch Java Web Start in system mode, or if you just launch "javaws -system".

By using the new modality features added by AWT in Java 6, You can now interact with the Java Console even when the Application is displaying a modal Dialog.

Java Web Start and Java Java Plug-in now support CRL (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol) for verifying the certificates.

An Option has been added to the Java Control Panel to select the default SSL handshaking protocol.
The default is set to SSLv3 and SSLv2, but then user or enterprise can change it to TSL.