|FREQUENTLY ASKED QUESTIONS|
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. By using any Web browser, end-users can launch the applications and be confident they always have the most-recent version. back to top
Click here to download Java Web Start.
Go to the README for comprehensive instructions on downloading, installing, and using Java Web Start if you are an end-user.
If you are a developer, go to the Developer's Guide for concise, detailed technical information on how to deploy applications using Java Web Start.
If you are a site architect, go to the Architecture Page for examples of the types of Web-based solutions that are enabled by Java Web Start and the Java 2 platform, or to the Java Web Start Architecture diagram for more information on how Java Web Start functions. back to top
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 applications based on Java 2 technology, 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. back to top
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 TM Web Start will ask the second time you launch an application if you would like to create shortcuts or an entry in the Start Menu. If you say "yes," all future launches of the application can start without a browser.
Java Web Start also provides an Application Manager, which is launched by clicking on the icon on your desktop if you are running the Microsoft Windows operating system, or by using the <install-dir>/javaws command on Solaris Operating Environment and Linux platforms. The Application Manager keeps track of all applications that have been downloaded and launched using Java TM Web Start, and allows you to directly launch them.
As of JAWS 1.4.2, JNLP URLs are also directly openable from the JAWS Application Manager and can be bookmarked. Moreover, they may be
.jnlp files. back to top
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 Web Start Application Manager.
Java Web Start always checks to see if a newer version of the application is available for use and automatically downloads that from the Web for you.
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. back to top
Any client system that supports the Java 2 platform can use Java Web Start. Java Web Start works with virtually all browsers. back to top
Java Web Start uses the HTTP protocol for communication between the client and the server. A standard unmodified Web server can be used to host an application.
If you require additional services, such as version-based and incremental updates for your applications, the Web Server will need to support Servlets or cgi-scripting. back to top
Yes, the Java Community Process is a series of public meetings in which the definition of the Java TM technology was created.
Java Network Launching Protocol is a technology which is a part of the JCP standard. Its specification number is JSR 000056, the Java Network Launching Protocol and Application Programming Interface (JNLP).
Java Web Start 1.0 is the product-quality reference inplementation for the JNLP technology described above, therefore 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.
Thus, you can implement this protocol in any product, however note that additional licensing and terms must be met to implement any JCP technology including the JNLP technology. back to top
Java Web Start supports primarily Internet Explorer 4 or higher and Netscape 4.X. However JNLP files can be launched from any browser if the mime-type association is done correctly. Please note that Java Web Start uses the browsers settings and may launch a browser to show a URL these may/may not work with unsupported browsers.
Java Web Start works with Netscape 6. However, you will manually need to register Java TM Web Start with NS6. This is done in the Navigator/Applications section of the Navigator/Helper Application section.
This will be done automatically in a later version of the Java TM Web Start installer. back to top
Localized versions of Java Web Start have been bundled inside the international version of J2SE since 1.4.2. back to top
* Product Page:
* Developer's Guide:
Java Web Start is an application launcher for Java 2 technology based 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 ClassLoader getResource or another method. Java TM 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. back to top
Sitraka Software's free DeployDirector for JNLP automatically generates the required XML files and .WAR file needed by the server to deploy the bundle. back to top
Java Web Start is an application launcher for Java 2 technology-based 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 TM 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. back to top
Java Web Start is an application launcher for Java 2 technology-based applications that are written to be Web-deployed. It launches only those applications written on the Java 2 platform.
Java Web Start caches resources locally on the disk, but this is only one aspect of its technology. It 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. back to top
Java Web Start is an application launcher for Java 2 technology-based applications that are written to be Web-deployed. It launches only those applications written for the Java 2 platform. back to top
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 browsers, 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 enables users to run Java 2 technology-based 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 is not dependent upon 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. back to top
Licensing and Support Questions
Yes, Java Web Start can be bundled with your application. back to top
This release includes Sun's standard Binary Code License (BCL) + any supplemental terms, similar to the JRE terms. In general the terms tend to boil down to "you must ship is as, without modification." back to top
Java Web Start will always launch the application from the cache, if possible, and it will simultaneously perform a background check with the server for updates. If updates are available, then it will notify the user, and launch the update versions the next time. This approach ensures fast startup time in the common case where there is no update, and also makes sure that an application can be launched offline.
For the 1.0 release, this behavior can be overwritten by adding the line javaws.cfg.forceUpdate=true in a client's javaws.cfg file. This will force Java Web Start to check for an update the first time. Unfortunately though, setting this flag will cause offline mode to not work properly.
In a future release of Java Web Start, we expect to change the behavior of the update checking to immediatly launch the newer version of the application, if an update is available, while still preserving offline launching. back to top
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 all your application resources (such as images and resource bundles, for example) are retrieved from a JAR file, since Java TM Web Start launches an application by invoking the public static void main(String args) method.
And if your application needs unrestricted access to the system, (for example, network or disk access), you will need to sign your code. back to top
Java Web Start is primarily designed for application deployment. You specify all requirements for your application in the JNLP file, and off you go. We do provide the ability to launch Applets in much the same way as the traditional AppletViewer. The built-in AppletViewer is there to provide 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 certain limitation, e.g., you can not specify class files as resources and policy files are not accepted. back to top
Java Web Start allows certain JVM flags to be set in the JNLP file. Allowing the complete set could compromise security as well as limit portability across different platforms and implementations. Properties (-D) can be set using the
<property name="..." value=".."/>
element in the <resources> section. The maximum and initial heap size can be set using the initial-heap-size and max-heap-size attributes of the j2se element, e.g.,
<j2se version="..." max-heap-size="100M"/> back to top
Java Web Start 1.0 supports versioned JARs and incremental update. You have the ability to specify exact versions of the JAR files you want, instead of relying on the time-stamp information to know if an update is available.
Using version-id's also allows you to provide incremental updates from one version to another.
See the JNLP specification for the details:
Each JAR file that a JNLP Client (such as Java TM Web Start) downloads, is uniquely identified with a URL. If two JNLP files uses the same URL, then the resource will only be downloaded once and shared. This is similar to the caching implementations with Internet browsers. back to top
Java Web Start relies heavily on the new security model introduced with Java 2, and would be very hard (if not impossible) to implement on top of JRE 1.1.x. Therefore, the answer is no. back to top
Java Web Start needs to put up the initial splash screen, since at that point there is no application specific code. Downloading the application code might take a few seconds to several minutes. That is too long to wait to get the initial splash screen.
It is important that all applications launched through Java TM Web Start have an initial common look, so the security paradigm that this model implies, can be properly communicated to the end user.
An application can be written, so the initial download is rather small, e.g., in the order of 10 - 20 K. The initial download will then put up the initial application splash screen, and then proceeds to download the rest of the application. back to top
A sandboxed application can store state, using the PersistenceService APIs.
This API is somewhat similar to cookies for HTML pages. Thus, it will be a secure way of persistently store information locally on the client computer.
Please refer to the Specification and Developers Guide for more information:
A <j2se version="..."> specifies a platform version. Currently, there are two revisions of the Java 2 platform, 1.2 and 1.3.
The 1.2 platform is implemented by e.g Sun JRE's 1.2, 1.2.1, 1.2.2-w, etc.
The 1.3 platform is implemented by e.g Sun JRE's 1.3.0 so far.
You can request a specific product version by including a vendor URL. For Sun's JREs that will be
Thus, the following J2SE tag will request any Sun 1.2.2 implementation.
<j2se version="1.2.2*" href="#"/>
You can see all the versions of the installed JREs by inspecting the preferences panel of Java Web Start's built-in application manager. back to top
This is currently not possible since the URLs in the <jar> elements are all relative to the in the codebase attribute. However, the codebase attribute cannot be relative. However, we are looking at alternate solutions to solve this problem in a future release. back to top
The JNLP specification defines an extension mechanism that covers standard extension. Thus, you will be able to specify exactly a version of an extension you need and have it automatically downloaded and installed.
back to top
Java Web Start does not support the Class-Path entry in the manifest file. The Class-Path attribute is entirely file-centric, where as 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, e.g.,:
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 is specified in the specification.
JNLP also implements a just-in-time downloading mechanism, just as for Applets. For each resource in a JNLP file, you can specify which parts should be eagerly or lazily downloaded, i.e., before the application is launched and which ones can be downloaded 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. back to top
Java Web Start can be used to deploy Java Technology-based applications that also depends on native code. The <nativelib ...> element can be used to specify native libraries (such as DLLs or .so files) that an application depends on. 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, make sure to use the classloader that loaded your application, e.g.,:
Also ensure that the above happens in the main thread. back to top
You can launch for example:
Please ensure your path to javaws is set up correctly in your shell or Windows System properties. back to top
The JNLP 1.0 specification requires all JAR files used in a single JNLP file to be signed by the same certificate. This restriction avoids having the user to accept multiple certificates from the same source, as well as it allows Java Web Start to know if the user has accepted all certificates that are used for a particular application.
JAR files that are signed with different certificates can still be used with Java Web Start. If the JAR files contain code from different packages, they can be places in different JNLP files, by use of the component extension mechanism. To do this, instead of the following:
<extension name="Java Help" href="help.jnlp"/>
and then add a help.jnlp file with the following contents:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="http://ws503" href="Help.jnlp">
<vendor>Sun Microsystems, Inc. </vendor>
back to top
Java Web Start does not consider a non-FCS JRE to match a request for a particular platform version. For example, a request of the form <j2se version="1.4+"> does not consider an installed "1.4.0-beta" JRE as a match for the request. A JRE from Sun Microsystems, Inc. is by convention (starting from 1.3.0) a non-FCS if there is a dash (-) in the product version string. An application wishing to run under any beta J2RE must explicitly specify a product version, i.e., also using the href attribute in the j2se element. For example, a proper request for a beta JRE:
< j2se version="1.4-beta" href="http://bit.ly/xyGWeN"/>
In Java Web Start all applications are (by default) launched in a secure "sandbox."
Security is a key consideration of the Java Web Start design. However, Java Web Start provides a flexible and a secure sandbox. back to top
Applications have restricted access to local computing resources such as the disk and network, by default. back to top
All applications, by default, are run in a sandboxed environment, similar to the Applet sandbox. However, Java Web Start provides secure APIs that allows an application to import and export files from the local disk under the users control. Thus, the APIs ex: File Save, File Open etc., are dialogs actually rendered by Java TM Web Start, and not by the application itself.
This support is not much different from what you can do with HTML. A file input field in an HTML form allows exactly the same, i.e., for the user to pick a file from the local disk, which name (excluding path) and content will be submitted to the Web server. Similar for export, most browsers support the 'Save as...' option. back to top
An application requesting unrestricted access must be digitally signed. Therefore, the first time a user launches an application (with unrestricted access), a security dialog will appear. In which case Java TM Web Start will prompt the user for acceptance of the digital security signature, before the application is opened. After the user has accepted the certificate will not be shown for subsequent invocations. back to top
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.
The data that the application transferred between the client and the server must be encrypted. That is done at the application level. back to top
The security warning dialog box warns the user that an application has requested unrestricted access, and asks the user to accept this request or not. The dialog shows information about the origin of the code based on the certificate used to sign the code. This is so the user can make an informed decision on whether to trust the application or not.
The certificate used to sign the code is validated against a set of trusted root certificates. These are typically the root certificates from Certificate Authorities (CAs) such as VeriSign and CyberTrust.
If the certificate can be validated against one of these trusted root certificates, the following message will be shown: (Assuming signed by XYZ)
|Caution:||<XYZ> asserts that this content is safe. You should only install and run this application if you trust <XYZ> to make this assertion.|
If the certificate can not be validated against any trusted root certificate, then the signing certificate cannot be authenticated and the user has no assurance that the information in the certificate is valid. In that case, then the following message will be shown:
|Warning:||Failed to verify the authenticity of this certificate. No assertions can be made of the origin or validity of the code.|
This will e.g. happen if you use a self-signed test certificate.
Java Web Start ships with a complete set of trusted root certificates.
Please note that the JANET test certificate is discontinued in the 1.0 version. back to top
This typically happens when the Java Web Start can't find or launch the Java command for the default Java runtime environment (JRE). The JRE needs to be on your system with the correct version, before you can launch an application.
The simplest way to fix this is to re-install Java TM Web Start. Alternatively, you can edit the javaws.cfg file manually, please refer to the Readme file "Troubleshooting the Installation" section at :
back to top
A. This problem is likely to be caused by using a beta of the JRE 1.3.0 with Java Web Start. There is a known bug in the JRE 1.3.0beta release that causes Java TM Web Start not to work correctly. This bug is fixed in the final release of 1.3.0.
You can check what JRE you are using in the Preference panel (Java pane) in the Application Manager.
B. The cache may be corrupted you can clear the cache by using the Preference Panel in the Application Manager.
C. On Solaris: You may want to start Java TM Web Start from the command line which may give you more hints as to what could be wrong.
On Windows: You can start the JRE with a DOS Window by changing javaw.exe to java.exe in the Preferences->Java Panel.
See the Question on How can I start Java Web Start from command line. back to top
This is likely to happen in a network environment, which has a firewall between your computer and the internet and if the Java TM Web Start has not been configured with the right proxy settings.
You can set the proxies manually by using the Preference panel in Java Web Start's Application manager. back to top
You can rework the logic of your application not to use privileged and potentially unsafe operations. The same end result can be achieved in a secure sandbox safely, by using the JNLP APIs. Please the Developer's Guide for more details at: link
Alternately, you can sign the application and gain unrestricted access to all resources. back to top
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 Proxy servers, 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. back to top
Java Web Start 1.0 always downloads and uses the JNLP from the URL specified in the <jnlp href="..."> attribute, if the attribute is specified. The Web server must return the correct MIME type application/x-java-jnlp-file for that file.
See the Developer's Guide on how to configure your Web server to do this:
If the href attribute is not specified, the download does not happen and the JNLP file is not cached. Thus, you can overcome this by removing the href attribute. However, note that the user will not be able to create shortcuts (Windows-only) and that the application does not show up in the Application Manager. back to top
A certificate can only be trusted if you trust the certificate authority (CAs) that created the certificate. Java Web Start is shipping with a set of trusted root certificates of the most common CAs.
If you sign your application with a certificate that is authorized by someone and is not in the set of trusted root certificates, you will see the above warning message. This will, for example, happen if you use a self-signed certificate. back to top
This will happen if you are running in an environment with a proxy server. Thus, it will fail to load the resource.
To work around:
|*||Remove your proxy settings, i.e., clear both the proxy host and proxy port settings, and unchecked use browser settings in the preference panel, or|
|*||Use and exact IP address or name of the host, instead of localhost,e.g. 188.8.131.52.|
If a timestamp of the file on the IIS server is in the future IIS returns current-time as last-modified time. This make WebStart to reload the JARs since time-stamp is always newer. back to top
In the preference panel (Advance Tab) of the built-in Application Manager, turn on the 'Show Java Console' which will display all program output to System.out and System.err, you could also specify a log file in the same dialog box, to record all messages to a file of your choice. back to top
Check your JNLP file. If "initial-heap-size" is set, you would also need to set "max-heap-size". This bug will be fixed in the next release. back to top
This is a bug in the Java 2 SDK v1.2.2 or v1.3 . This bug will be fixed in a future Java 2 SDK release. In the meantime, there are a couple workarounds:
new JFileChooser(currentDirectory, new WindowsAltFileSystemView());here