This chapter includes the following topics:
Developing applications for deployment with Java Web Start is generally the same as developing stand-alone applications for the Java(TM) Platform Standard Edition. For instance, the entry point for the application is the standard public static void main(String argv).
However, in order to support Web deployment—automatic download and launching of an application—and to ensure that an application can run in a secure sandbox, there are some additional considerations:
Java Web Start only transfers JAR files from the Web server to the client machine. It determines where to store the JAR files on the local machine. Thus, an application cannot use disk-relative references to resources such as images and configuration files.
All application resources must be retrieved from the JAR files specified in the resources section of the JNLP file, or retrieved explicitly using an HTTP request to the Web server. Storing resources in JAR files is recommended, since they will be cached on the local machine by Java Web Start.
The following code example shows how to retrieve images from a JAR file:
// Get current
ClassLoader cl = this.getClass().getClassLoader();
// Create icons
Icon saveIcon = new ImageIcon(cl.getResource("images/save.gif"));
Icon cutIcon = new ImageIcon(cl.getResource("images/cut.gif"));
The example assumes that the following entries exist in one of the JAR files for the application:
Java Web Start addresses the security issues:
Applications launched with Java Web Start are, by default, run in a restricted environment where they have limited access to local computing resources, such as storage devices and the local network. In this sandbox environment, Java Web Start can guarantee that a downloaded and potentially untrusted application cannot compromise the security of the local files or the network.
An additional security feature supported by Java Web Start is digital code signing. If an application being invoked is delivered in one or more signed JAR files, Java Web Start will verify that the contents of the JAR file have not been modified since they were signed. If verification of a digital signature fails, Java Web Start will not run the application, since it may have been compromised by a third-party.
The support for code signing is important for both users and for application service providers. This service makes it possible for users to verify that an application comes from a trusted source. Because the application service provider signs the code, both can be ensured that no other party can impersonate the application on the Web. A signed application that is trusted by the user can also request additional system privileges, such as access to a local disk.
Java Web Start presents a dialog displaying the application's origin, based on the signer's certificate, before the application is launched. This allows the user to make an informed decision about whether or not to grant additional privileges to the downloaded code.
By including the following settings in the JNLP file, an application can request full access to a client system if all its JAR files are signed :
The implementation of code signing in Java Web Start is based on the security API in the core Java(TM) Platform Standard Edition. The Java 2 SE JRE 1.4.2 supports code signing with the SHA1withDSA and MD5withRSA algorithms.
Developers sign code for use with Java Web Start in the same way as for Java Applets—by using the standard jarsigner tool from the Java(TM) Platform Standard Edition. The jarsigner tool documentation provides examples of how to sign code and create test certificates, and it discusses other issues related to signing.
Java Web Start also supports use of the Netscape signtool used with SDK/JRE 1.4.2. See the Netscape Web site for details: http://developer.netscape.com/software/signedobj/
Here are the steps needed to sign a JAR file with a test certificate:
1. Make sure that you have an SDK 1.4.2
in your path. These tools are located in the SDK bin directory.
2. Create a new key in a new
keystore as follows:
keytool -genkey -keystore myKeystore -alias myself
You will get prompted for a information about the new key, such as password, name, etc. This will create the
myKeystorefile on disk.
3. Then create a self-signed test certificate as follows:
keytool -selfcert -alias myself -keystore myKeystore
This will prompt for the password. Generating the certificate may take a few minutes.
4. Check to make sure that everything is okay. To list the contents of the keystore, use this command:
keytool -list -keystore myKeystore
It should list something like:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry:
myself, Tue Jan 23 19:29:32 PST 2001, keyEntry,
Certificate fingerprint (MD5):
5. Finally, sign the JAR file with the test certificate as follows:
jarsigner -keystore myKeystore test.jar myself
Repeat this step with all of your JAR files.
Note that a self-signed test certificate should only be used for internal testing, since it does not guarantee the identity of the user and therefore cannot be trusted. A trust-worthy certificate can be obtained from a certificate authority, such as VeriSign or Thawte, and should be used when the application is put into production.
Beginning with Java Web Start version 1.2, JNLP files may be encoded in any character encoding supported by the Java(TM) Platform Standard Edition. (See the Java(TM) Platform Standard Edition documentation for a list of supported encodings.)
To encode a JNLP file, specify an encoding in the XML prolog of that file. For example, the following line indicates that the JNLP file will be encoded in UTF-16.
<?xml version="1.0" encoding="utf-16"?>
The XML prolog itself must be UTF-8-encoded.
Beginning with 1.4.2, Java Web Start dynamically imports certificates in much
the same way as browsers do. In order to make this work, Java Web Start now
sets its own https handler, using the
system properties, to initialize defaults for
HostnameVerifier. It sets the defaults with
If your application uses those two method, make sure they are called after
the Java Web Start https handler is initialized, otherwise your custom handler
will be replaced by the Java Web Start default handler. You can ensure that
your own customized
are used by doing either of the following:
HttpsURLConnection.setDefaultHostnameVerifieronly after the first https url object is created, which will execute the Java Web Start https handler initialization code first.
For information on creating a download servlet see the next chapter, JnlpDownloadServlet Guide.