Java Web Start enhancements in version 6

• JNLP Specification addition of the <update> element with its "policy" and "check" attributes.

The new <update> element with its "policy" and "check" attributes is now supported. The update element describes the applications preferences on 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 while the update check continued in the background.
With the advent of the <update> element and its 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".

• JNLP Specification relaxation of requirements for the DownloadService API.

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 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).

• Implementation of a SocketService

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.

• New <java> element in jnlp file to replace <j2se> element.

For jnlp files that will be used only 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..

• The <association> element now may contain the <icon> and <description> sub-elements.

When creating file extension and mime type associations with your 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).  Now, you can also specify a description.

• Jar Indexing is fully supported now, and the JNLPClassLoader is now an instance of the URLClassLoader.

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 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.

• Enhanced icon support.

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 its 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 separate images for any desktop and menu shortcuts that are 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 )

• Enhanced support for Add/Remove program entries on Windows.

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 shortcut tooltips.

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

• JNLPDownloadServlet enhancements.

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.

• The list of safe vm args and safe properties has been expanded.

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

• Several Command Line Interface (CLI) items have been changed or added. See the developers guide for the current Javaws CLI.

Enhancements Common to Java Web Start and Java Plug-in

• All dialogs have been redesigned to be more user friendly.

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.

• DownloadEngine and cache consolidation and redesign.

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 vice versa.

• Caching can be disabled now 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 "cache-control: no-cache" HTTP header is now supported. "no-cache" means cached contents cannot be used without re-validation. When the no-cache directive is used , an update check is always made to make sure the cached content is the same as the server copy pointed to, by the resource URL. If so, cached copy can be used. If not, server copy will be downloaded. Expiration field is ignored, which means that even if the cached resource is not expired yet, update check will still be performed.

• 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".

• The Java Console is now excluded from modality.

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

• New support for OCSP/CRL

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

• New Support for SSL/TSL

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.