<j2se version="1.3" initial-heap-size="64m" max-heap-size="128m"/>
<j2se version="1.4.2+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-esa -Xnoclassgc"/>
FAQ Update (March 2006)
March 2006 Updates:
Where can I find the Web Start chat session transcripts from March, 2005 ?
What are some troubleshooting hints for Web Start applications?
What is the story on auto-downloading jres?
See the notes on the import feature and CD-Install here
How do you use the Enterprise Configuration features?
Java Web Start provides a platform-independent, secure, and robust deployment technology. It enables developers to deploy full-featured applications to end-users by making the applications available on a standard web server. With any web browser, end-users can launch the applications and be confident they always have the most-recent version.
Look at the online documentation for Java Web Start .
It's an easy, robust, and secure way to deploy applications directly from the web. Developers can make applications readily available via the web. In addition, Java Web Start provides Java runtime environment (JRE) management capabilities, it's easy to set up, it's browser-independent, and it's an efficient way to deploy web application solutions.
Users can easily access applications much as they would a web page--without a separate installation step. From the desktop, users can access and use Java applications, using a richer and more responsive user interface than is available on a web page. And, once a Java Web Start based application is installed, users simply click to run the application whenever needed.
Users do not need to manually update applications because each time they launch an application, it is transparently updated from the web--so they always use the most recent version available.
You initially launch a new application by clicking on a link from a web page.
If you use an application frequently, create a shortcut from your desktop or from the Start Menu by allowing Java Web Start to place an icon on your desktop. Java Web Start may ask if you would like to create
Java Web Start also provides an Application Cache Viewer which you can launch from the Java Control Panel. The Cache Viewer enables you to directly launch applications you have downloaded.
You can also launch an application from a command prompt by typing “javaws <jnlp_url>” where <jnlp_url is a url to the jnlp file of the application.
No, applications launch in the same manner no matter which method you use: from a web page, from the shortcut on the desktop, from the Start menu, or through the Java Application Cache Viewer.
Java Web Start always checks to see if a newer version of the application is available for use and automatically downloads it if so.
If the application you are using has not been digitally signed, Java Web Start will launch it in a restricted and secure execution environment. An application that is not signed, or one that you do not trust, will never be run with unrestricted access to your local system or network.
Any client system that supports the Java version 1.2.2 or higher can use Java Web Start. Java Web Start works with virtually all browsers.
Sun Microsystems provides versions for Windows 98/NT/2000/XP/2003, Solaris Operating Environment (SPARC and Intel editions) and Linux/i486. Apple provides a version for their OS X release.
Java Web Start uses HTTP for communication between the client and the server. You can use a standard web server to host an application. If you require additional services, such as version-based downloading, incremental updates, or pack200 compression for your applications, the web server will need to support servlets or Java Server Pages. A sample servlet implementing these features is provided in the samples directory of the JDK.
Yes. Java Web Start 1.5.0 is the product-quality reference implementation of Java Network Launching Protocol (JNLP) technology, which was developed through the Java Community Process. JNLP is specification number JSR 056. Other platform vendors are encouraged to port Java Web Start to their platform or implement the specification.
The underlying technology for Java Web Start, the Java Network Launching Protocol and API is being developed through the Java Community Process, so you can implement this protocol in any product. However additional licensing and terms must be met to implement any JCP technology including the JNLP technology.
Java Web Start supports primarily Internet Explorer 4 or higher and Mozilla. However any browser can launch JNLP files if you have set the MIME-type association correctly. Java Web Start uses the browser's settings and may launch a browser to show a URL; this feature may not work with unsupported browsers.
Java Web Start is an application launcher for Java applications that are written to be web-deployed.
An application must be delivered in a set of JAR files and all application resources, such as images, configuration files, and native libraries must be included in the JAR files. The resources must be looked up using the method ClassLoader.getResource() or an equivalent method. Java Web Start only transfers JAR files from the web server to the client.
If an application is written to run in a restricted execution environment (sandbox), then access to disk is not permitted and the application may only connect to the host on which it resides.
Is Java Web Start a software distribution mechanism like Marimba and MS SMS?
Java Web Start is an application launcher for Java applications. It allows easy distribution of full-featured applications based on the Java platform from a web server to a client machine with minimal user interaction.
The software distribution technology is only one aspect of Java Web Start. It also provides security, updates to the applications, ease-of-use for end users, and flexibility for developers when they create the applications.
Java Web Start is an application launcher for Java applications that are written to be web-deployed. Java Web Start caches resources locally on the disk, but also provides a secure execution environment and a virtually transparent updating facility for applications. The end user does not need to manually initiate a software update because the application is updated each time it is used.
Java Web Start launches only applications written for the Java platform versions 1.2.2 and higher.
The two approaches are very similar. The key difference is in the user experience. If the Java application/applet needs to interact with a web page and be tightly bound to a web browser, then applets may be the solution. On the other hand, if browser independence is important, then Java Web Start is the deployment platform of choice. There are a number of other differences, but this is the fundamental difference.
Java Plug-in technology enables users to run Java applets inside a browser.
Java Web Start enables users to download full-featured applications with any browser. Once they have downloaded and launched an application, the browser can be closed, while the application continues working. The application does not depend on an open browser to function. The browser can be shut down or you can go to a different web page and the application will continue running.
If your application is written to the Java 2 platform, and is delivered as a set of JAR files, there should be no need to revise your application. Make sure that your application retrieves all its resources (such as images and resource bundles) from a JAR file, since Java Web Start launches an application by invoking the public static void main(String args) method.
If your application needs unrestricted access to the system, (for example, network or disk access), you will need to sign your code.
Java Web Start is primarily designed for application deployment. You specify all requirements for your application in the JNLP file, and off you go. It does provide the ability to launch applets in much the same way as the traditional AppletViewer. The built-in AppletViewer provides an easy migration path for existing applets that want to take advantage of Java Web Start. However, it is not intended to be a full implementation of the Plug-In. The Plug-In is the primary launching vehicle for applets. The built-in AppletViewer in Java Web Start has limitations, for example, you cannot specify class files as resources and it does not accept policy files.
Java Web Start allows certain JVM flags to be set with the
<j2se version="..." max-heap-size="100M"/>
Java Web Start supports versioned JARs and incremental updates. You can specify exact versions of the JAR files you want, instead of relying on timestamp information to determine if an update is available. Using version IDs also allows you to provide incremental updates from one version to another. See the JNLP Specification or the Developer's Guide for details.
Each JAR file that a JNLP Client (such as Java Web Start) downloads, is uniquely identified with a URL. If two JNLP files use the same URL, then the resource will only be downloaded once and shared. This is similar to the caching implementations used by web browsers.
Java Web Start needs to put up the initial splash screen while Java is loading. For subsequent access, you can specify an image file to use for the splash screen in the JNLP file with the tag
<icon href="mysplash.jpg" kind="splash"/>
A sandboxed application can store state using the PersistenceService API. This API is similar to cookies for HTML pages. Thus, it is a secure way to store persistent information on the client computer. For more information, see:
The tag <j2se version="versionNum"> specifies a platform version, where versionNum is 1.2, 1.3, 1.4, or 1.5.
You can request a specific product version by including a vendor URL in the href attribute. For Sun's JREs, the URL is http://java.sun.com/products/autodl/j2se For example, the following J2SE tag will request any Sun 1.3.1 implementation:
<j2se version="1.3.1*" href="http://java.sun.com/products/autodl/j2se"/>
You can see all the versions of the installed JREs in the Java tab of the Java Control Panel.
Java Web Start does not support the Class-Path entry in the manifest file. The Class-Path attribute is entirely file-centric, whereas Java Web Start and JNLP is web-centric, i.e., based on URLs. Thus, the two models do not merge easily.
Instead of relying on the Class-Path entry, you can list multiple JAR files in the JNLP file, for example:
In a JNLP file, you can factor out dependencies on a set of JAR files to another JNLP file using the <extension... > element. Thus, you can achieve the same kind of re-usability and ease of maintenance as you do with the Class-Path entry. This feature is described in the specification.
JNLP also implements a just-in-time downloading mechanism, similar to applets. For each resource in a JNLP file, you can specify which parts should be eagerly or lazily downloaded. Eagerly loaded resources are loaded before the application is launched, lazily loaded resources later. Default is eager download. Furthermore, the specification includes an API for which you can programatically query Java Web Start about which resources are available and request them to be downloaded. Thus, you can write download/network aware applications.
You can use Java Web Start to deploy Java Technology-based applications that depend on native code such as DLLs and SOs. Use the <nativelib ...> element to specify required native libraries. See the Developer's Guide for details.
Java Web Start uses a user-level classloader to load all the application resources specified in the JNLP file. This classloader implements the security model and the downloading model defined by the JNLP specification. This is no different than how the AppletViewer or the Java Plug-In works.
This has the, unfortunate, side-effect that Class.forName will not find any resources that are defined in the JNLP file. The same is true for looking up resources and classes using the system class loader (ClassLoader.getSystemClassLoader).
To find application resources in Java Web Start, use the classloader that loaded your application, for example use the following call in the in the application;s main thread:
You can also use:
You can launch Java Web Start from the command line as follows:
javaws [options] your-app-JNLP-URL
where your-app-JNLP-URL is the location of your application's JNLP file. For example:
The JNLP 1.0 specification requires all JAR files used in a JNLP file to be signed by the same certificate. This restriction avoids requiring the user to accept multiple certificates from the same source, and enables Java Web Start to know if the user has accepted all certificates used for an application.
However, Java Web Start can use multiple JAR files signed by different certificates, by using the component extension mechanism and multiple JNLP files. The only requirement is that the JAR files contain code from different packages. So, instead of the following:
Use the following:
Then add a help.jnlp file with the following contents:
<?xml version="1.0" encoding="utf-8"?>
This is most likely happening because your web server is not aware of the proper MIME type for JNLP files. Java Web Start requires only one change to your web server, that is creating an association between the file extension, typically jnlp, and the MIME type, application/x-java-jnlp-file. The steps for doing this vary depending upon the web server you are using.
Furthermore, if your corporation uses a proxy server, ensure that the update versions of the files are returned, by updating the time stamp of the resources on the web server such that the proxies will update their caches.
If a timestamp of the file on the IIS server is in the future IIS returns current-time as last-modified time. This makes Java Web Start to reload the JARs since time-stamp is always newer.
Yes. The JnlpDownloadServlet distributed in the samples directory of the JDK now supports Pack200. If you deploy yourfile.jar along with yourfile.jar.pack.gz the packed file will be downloaded when the client is running Java Web Start 1.5.0 or later.
Use the SingleInstanceService to register as a singleton as soon as your application starts up. Re-invoking your application before it is registered as a singleton will cause another Java VM to start up.
Make sure to unregister before your program exits.
Normally, properties in the jnlp file will not be set until the first resource listed in that jnlp file is loaded. This insures the properties are set before any of your code is run, however some properties need to be set before other packages are loaded. Some properties are considered to be “secure” by Java Web Start, and, when found in the main jnlp file, will be passed as arguments to the invoking VM (-Dname=value).
You click on a jnlp file, and Internet Explorer downloads the file, then launches Java Web Start, but you get the message: “Could not load file/URL specified: C:/Documents and Settings/.../application.jnlp”.
This problem is specific to Internet Explorer. Although this can be caused by a full cache, or turning off the cache in IE, it is usually caused by a no-cache directive coming from either the web server or the proxy server. IE will honor this directive, and not write the jnlp file to disk, so Java Web Start cannot find it. This frequently happens when upgrading a tomcat based server. Later versions set the no-cache directive by default for any resource that is within a security-constraint in web.xml. Try taking the relevant URI out of the security constraint in web.xml.
Beginning with Java Web Start 1.5.0, you can multiply sign the jar, adding code signing certificates over another existing certificate chain. With previous versions, you would either have to run the jar as a component extension w/o all-permissions, or strip the existing certificates before adding code signing certificates. (which in many cases rendered the package inoperable.)
The association feature specifically requires libgnomevsf-2.so. If this library is not present, associations are not supported.
Each web server has a specific way in which to add MIME types. For example, for the Apache web server you must add the following line to the .mime.types configuration file:
Check the documentation for the specifics of your web server.
An application is normally identified by it's href (the url to it's jnlp file.) If there is no href to the jnlp file, it is identified by the href to it's main jar file. If multiple applications share the same main jar file, they must contain an href, or they will be treated as the same app.
In version 1.5.0 and beyond, the Java Application Cache Viewer, will show all applications, even those w/o an href. The Viewer can only launch an application online, if it has an href. Without an href, it can launch offline if the jnlp file allows (contains <offline-allowed>)
In previous versions, the Application Manager will only show those applications with an href.
The same thing applies to creating shortcuts. In 1.5.0 you can only create a shortcut to launch online if there is an href, and can only create an offline shortcut if <offline-allowed> is specified. In 1.4.2, you can only create shortcuts to applications with an href.
When creating multiple file-extension/mime-type associations with your JNLP application, it's recommended that you use multiple association tags. Also, both the file-extension and mime-type must be specified for each association tag. For example:
<association extensions="aaa" mime-type="x-application/aaa"/>Back to top
Security is a key consideration of the Java Web Start design. In Java Web Start all applications are launched by default in a secure "sandbox."
Applications in the secure sandbox have restricted access to local computing resources such as the disk and network.
All applications, by default, are run in a sandboxed environment, similar to the applet sandbox. However, Java Web Start provides a secure API that enables an application to import and export files from the local disk under the user's control. The API includes dialog boxes for operations such as saving a file and opening a file that are actually rendered by Java Web Start, and not by the application itself.
This sandbox design is similar to what you can do with HTML. A file input field in an HTML form enables a user to pick a file from the local disk and submit the name (excluding path) and content to the web server. Similarly, most browsers support the 'Save as...' option.
An application requesting unrestricted system access must be digitally signed. The first time a user launches such an application, a security dialog box will appear. Before running the application, Java Web Start will prompt the user to accept the digital certificate. After the user has accepted the certificate, subsequent invocations will not show the security dialog box.
Support for encrypting data transferred from the server to the client is very important. This is an important point on our issue list, and we will definitely make sure that HTTPS libraries will work with applications that are launched with Java Web Start. The HTTPS support might be in an optional package that you need to specify that your application depends on.
Encrypting the JAR files transferred from the server to the client may not be necessary. The reason is, even if the class files where encrypted on the wire, they will have to be decrypted on the client side and stored to disk, so the JVM will be able to load the classes. Thus, it could be fairly simple for a cracker to get around the encryption of the JAR files.
Instead, what is important for JAR files is that they can be signed, so the user can be absolutely sure that the application is from the vendor he expect it to be from. This is already supported.
NTLM support was added to Java 1.4.2 on Windows platforms only. You can use NTLM authentication with Java Web Start in 1.4.2 and beyond. The JAuthenticator dialog may contain some misleading text when using NTLM with Java Web Start 1.4.2, but this is fixed in Java Web Start 1.5.0.
HTTPS support was added to Java in version 1.4. You can use use HTTPS protocol for Java Web Start resources starting in version 1.2, but may encounter one of several problems that were addressed in Java Web Start 1.4.2. It is recommended to use at least Java Web Start 1.4.2 if using HTTPS protocol.
See the following:
In version 1.4.2 only.
This is the problem where the desktop integration dialog fights for focus with a modal dialog displayed by the application, or the dialog is lost behind another application window.
This is fixed in versions 1.4.2_06 and 1.5
In all versions.
If you have multiple native libraries, you must load each library with System.LoadLibrary, before loading any other that references it. This may become impossible if libraries have circular dependancies.
In versions 1.2 and 1.4.2
If TraceSecurity is turned on, you may get an exception on Windows platforms if there is a space in the path to the cache directory. If you have this problem turn off the TraceSecurity debugging switch (<property name=”javaws.debug.0” name=”-TraceSecurity” />.
This is fixed in version 1.5.
In version 1.5.0.
In the specification of the jnlp file, it is legal to specify a related-content element without a title sub-element. However if this is done on windows platforms, an exception will be thrown when the shortcut to the related content is installed, and the program cannot be run. To work around this problem, always include a title for related-content elements.
In all versions.
If a component extension is used, the first jar in it will be download eagerly, even if it is marked lazy.
In all versions.
If you use the part and package mechanisms to declare what packages are included in what jar files, you should be able to skip downloading of any lazy jars so declared, when accessing a non-existent resource not in any of the declared packages. This does not work, and without Jar Indexing implemented, there is no way to prevent all jars from being downloaded.
In version 1.5.0.
When using the FileOpen Service, the security dialog will only show if the application does not have file access permissions. This is not true with the new ExtendedService OpenFile, and OpenFiles methods, the security dialog shows anyway.
In version 1.5.0.
When importing applications into the system cache with -shortcut, or running the Cache Viewer in system mode and creating shortcuts. The shortcuts should be created for all users. This works in Windows, but not on Unix with Gnome.
In all versions.
If an Exception or other Throwable is not caught by Java Web Start. The main run method may terminate without calling System.exit(). This makes application appear to hang (sometimes with DownloadProgress window showing with no progress).
In 1.4.2 this can happen when the Application or Java Web Start throws an Error (such as a NoSuchMethodError). You may need to turn on logging to a file and run with <property name=”javaws.debug.0” value=”+TraceIgnoredExceptions” /> to see the Error.
In 1.5.0 this is only known to happen if static code in the applications main class throws an Error (such as a NoSuchMethodError).
In all versions.
When Java Web Start finds multiple JRE's that satisfy the requirements of the j2se elements version attribute in the jnlp file, it should always use the latest matching version.
In 1.4.2 it will usually just use the first matching version found.
In 1.5.0 it will usually use the latest version, but under some specific circumstances will still use an earlier one.