This chapter includes the following topics:
Developing applications for deployment with Java Web Start is generally the same as developing standalone applications for the Java Platform, Standard Edition. For instance, the entry point for the application is the standard public static void main(String[] argv).
However, to support web deployment—automatic downloading and launching of an application—and to ensure that an application can run in a secure sandbox, there are some additional considerations:
An application must be delivered as a set of signed JAR files. All entries in each JAR file must be signed.
All application resources, such as files and images, must be stored in JAR files. The resources must be referenced using the getResource mechanism in the Java Platform, Standard Edition.
If an application is written to run in a secure sandbox, it must follow these restrictions:
No access to a local disk.
All JAR files must be downloaded from the same host.
Network connections without user prompts are enabled only for the host from which the JAR files are downloaded. Connections to other hosts require approval from the user.
No security manager can be installed.
No native libraries can be used.
Limited access to system properties. The application has read/write access to all secure system properties defined in the JNLP file, as well as read-only access to the same set of properties that an applet has access to.
Some of these restrictions can be overcome by the use of the JNLP API to access the file system and other system resources.
An application is allowed to use the System.exit call.
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, because 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 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:
images/save.gif images/cut.gif
The JNLP API can be used to access the client's file system and other resources. See the following topics for more information about using the JNLPI API to access the client:
Java Web Start addresses the following 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.
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, then 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, then Java Web Start will not run the application, because it might 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. 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 box that displays the application's origin, based on the signer's certificate, before the application is launched. This enables 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:
<security> <all-permissions/> </security>
The implementation of code signing in Java Web Start is based on the security API in the core Java Platform, Standard Edition.
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 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.
For testing purposes, a self-signed certificate can be used to sign a JAR file. For production, use a code signing certificate issued by a trusted certificate authority.
These are the steps to sign a JAR file with a self-signed test certificate:
Ensure that you have an SDK keytool and jarsigner in your path. These tools are located in the SDK bin directory.
Create a new key in a new keystore as follows:
keytool -genkey -keystore myKeystore -alias myself
You are prompted for information about the new key, such as password and name. This creates the myKeystore file on the disk.
Create a self-signed test certificate as follows:
keytool -selfcert -alias myself -keystore myKeystore
This prompts for the password. Generating the certificate might take a few minutes.
Check to ensure that everything is OK. To list the contents of the keystore, use this command:
keytool -list -keystore myKeystore
The output should look similar to:
Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry: myself, Tue Jan 23 19:29:32 PST 2001, keyEntry, Certificate fingerprint (MD5): C2:E9:BF:F9:D3:DF:4C:8F:3C:5F:22:9E:AF:0B:42:9D
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, because it does not guarantee the identity of the user and therefore cannot be trusted. A trustworthy certificate can be obtained from a certificate authority, such as VeriSign or Thawte, and should be used when the application is put into production.
To run an application that is signed with a self-signed test certificate, do one of the following on the computer where the application will run:
Add the ___location of the application to the Exception Site List, which is managed from the Java Control Panel.
Import the test certificate into the User Signer CA store using the Java Control Panel or into the System Signer CA store using the keytool utility.
Encode JNLP files in any character encoding supported by the Java Platform, Standard Edition. See Supported Encodings in the Java Platform, Standard Edition Internationalization Guide for a list.
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.
Java Web Start dynamically imports certificates in a similar way as browsers do. To make this work, Java Web Start sets its own HTTPS handler, using the java.protocol.handler.pkgs system properties, to initialize defaults for SSLSocketFactory and HostnameVerifier. It sets the defaults with HttpsURLConnection.setDefaultSSLSocketFactory and HttpsURLConnection.setDefaultHostnameVerifier.
If your application uses those two methods, ensure that 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 SSLSocketFactory and HostnameVerifier are used by doing either of the following:
HttpsURLConnection.setDefaultSSLSocketFactory or HttpsURLConnection.setDefaultHostnameVerifier only after the first HttpsURLConnection object is created, which executes the Java Web Start HTTPS handler initialization code first.