Java Web Start enhancements in version 6
- JNLP Specification addition of the <update> element with
it's "policy" and "check" attributes.
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
- JNLP Specification relaxation of requirements for the
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
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).
- 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>
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
- The <association> element now may contain the <icon>
and <description> sub-elements.
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.
- Jar Indexing is now fully supported, and the JNLPClassLoader is
now an instanceof the URLClassLoader.
The JNLPClassLoader was rewritten to
extend URLClassLoader. This gives several powerful
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
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"
<icon kind="shortcut" href="desktopshortcut.ico" width="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 )
- 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 tooltip 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
- 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.
The following enhancements are in
common between 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
- 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 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
- 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
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 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.