Prior to Java SE 6, In Java Web Start offline-allowed element was overloaded for two things. First, the application can run in offline mode. Second, Try to check for updates before running an application (when not run in offline mode) could time out.
Java Web Start Enhancements in version 6
Enhancements in Java Web Start
-
JNLP Specification addition of the <update> element - The <update> element with its attributes "policy" and "check" is now supported. It 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 starting the application that there is an update available.
Prior to Java SE 6, In Java Web Start <offline-allowed> element was overloaded for two things. First, the application can run in offline mode. Second, Try to check for updates before running an application (when not run in offline mode) could time out. When a times out, the application would launched to the cache wile and the updates check continued in the background.
In Java SE 6, the "policy" attribute of <update> element is used to determine what to do when it is known before launching the application that an update is available. The values of policy attribute can be "always" (default value), "prompt-update" or "prompt-run". Because of "check" attribute of <update> element in version 6, the <offline-allowed> element has no more its second meaning that discussed above. Default values : <update check="timeout"/> has same behavior was specified by <offline-allowed> in previous version. Whenever <offline-allowed> was previously used, for that behavior you need to specify <update check="always"/>. A <update check="background"/> can be specified to always immediately launch from the cache while spawning a check for update in the background.
-
JNLP Specification relaxation is required for the DownloadService API - Upto now we used to pass the URLs as arguments to all APIs were restricted to be used a URLs to resources listed in the jnlp files. In this version there is not any such restrictions for signed and trusted code there is no restriction on untrusted code that it has to be listed in the jnlp files but the only requirement is that it should be from the same codebase.
But in current version, URLs to jnlp files are allowed, so that by using DownloadService.removeResource() you can remove a whole application from cache and by using DownloadService.load Resource() you can import an application. Due to this change now resources is not listed in jnlp file can now be used in an application.
-
SocketService Implementation - A clarification in the definition of the sandbox is also a another important specification change, that is only the default sandbox, this implementation is free to prompt the user to allow actions that are not allowed by the sandbox. In Java 1.5, it was done for printing, so that in AWT by using printing API, you can expand the sandbox for allowing the application to access the printer. But in Java SE 6, it is done for socket connection, that's why if an untrusted application try to connect to a url, the user can be prompted to allow the connection.
-
Replace <j2se> element by new <java> element in JNLP file - This element will be used only with Java Web Start version 6 for jnlp files. The <j2se> element is replaced by <java>tag (The main reason of behind that is only the Java Platform Standard Edition is no longer known as j2se).
-
Enhanced <association> element now contain the <icon> and <description> sub-elements - When creating file extension and mime type associations with Java Web Start application, you can specify description and a separate icon to be used for each association.
-
JNLP is now an instance of the URLClassLoader - It gives some powerful advantages. First, Jar indexing is now fully supported. If you want to create a jar index of several jar file in the main jar file that indexes all the jar files, and then you can mark each additional jar as lazy, and it can be download only when a resource or class in it is referenced. Second, The JNLPClassLoader was rewritten to extend URLClassLoader. For getting a list of jar elements that are listed in the jnlp files an application can invoke getURLs(). The URL returned for calls to Class Loader.getResource() is proper Jar URL of the item on the net. By extending URLClassLoader, it allows Java Web Start to operate without caching.
-
Java Web Start now supports icon formats - Now, two icon formats "png", "ico" are supported by Java Web Start. This enhancement allows to specify an icon that would not be translated into a different format depending on its use. Now you can specify a icon format kind="shortcut" with width and height attributes. Example - <icon kind="shortcut" href="desktopshortcut.ico" width="32" height="32"/> <icon kind="shortcut" href="menushortcut.ico" width="16" height="16"/>. For destktop shortcuts use the icon size is closer to 32 x 32 and for menu shortcut its closer to 16 x 16.
-
Add/Remove entries will now supported on Windows for Java Web Start - Add/Remove entries will now include will now include the publisher, install date, publisher websight and application icon from the jnlp file information block.
-
Desktop shortcut tooltips - Java Web Start creates a Desktop shortcuts. In Jnlp file Java Web Start will use the <description> element to create a tooltip for describing the application.
-
Enhanced JNLPDownloadServlet - Now, the enhanced JNLPDownloadServlet contains the two macro $$hostname and a $$sight. The expanded $$hostname contains the host name and $$sight contains the web site address without the WAR context portion.
-
The safe vm args and properties list has been enhanced and some Command Line Interface (CLI) items are also changed or added.
Java Web Start and Java Plug-in Common Enhancements
-
Cache and System Format
In Java SE 6, the cache format has been fully changed. That's why, any existing code using previous format of cache for Java Web Start or Java Plug-in will no longer work. Existing applications cache will be upgraded and converted to the new format of cache when the first time you launch a Java Web Start application, or by launching the cache viewer using javaws-viewer. And System cache will upgraded when the first time you run Java Web Start application in system mode, or just launching javaws - system.
-
Download Engine and Cache Consolidation
Download Engine and entire caching mechanism are redesigned and consolidated between Java Web Start and Java Plug-in. This include some new features in Java Web Start:-
By using Java Control Panel it allow to disable the caching.
-
The maximum cache size set in Java Control Panel is supported in Java Web Start.
-
A cleanup thread can be started by Java Web Start to removed Least Recently Used (LRU) items from the cache when approaching the maximum size.
-
The <no-cache> directive is now supported. When using this directive, and update check is made to verify the cached contents is same as at the URL.
-
The expiration-date is supported. If any download resource contains an expiration date, it will not be used after that date.
-
-
Secure Versioning
In Java SE 6, signed Java Web Start applications are not affected but the unsigned Java Web Start applications specify a version trigger a security warning, requiring explicit user permission before running the application.
-
Other Enhancements
-
All dialogs and screens have been redesigned by user experience team to be more user friendly and accessible.
-
Now, Java Console is not included in modality. In Java 6, some new features are added in modality by AWT. By this you can interact with Java Console even when the application is displaying a modal dialog.
-
CRL (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol) are supported by Java Web Start and Java Plug-in for verifying the certificates.
-
SSL/TSL are supported by Java Web Start and Java Plug-in. An option has been provided by Java Control Panel to select the default SSL handshaking protocol. The default is set to SSLv3 and SSLv2, but then user can change it to TSL.
-