作者：diego lynn
日期：2001-3-25 10:54:32
Application Development Considerations
Developing applications that can be deployed with Java Web Start are generally the same as developing a stand-alone application for the Java 2 platform. Hence, 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 the application -- and to ensure that an application can run in a secure sandbox, there are a few added considerations: 

An application must be delivered as a set of JAR files. 
  
All application resources, such as files and images must be stored in JAR files; and they must be referred to using the getResource mechanism in the Java 2 platform (see below). 
  
If an application is written to run in a secure sandbox, it must follow these restrictions: 
No access to local disk. 
All JAR files must be downloaded from the same host. 
Network connections are enabled only to the host from which the JAR files are downloaded. 
No security manager can be installed. 
No native libraries. 
Limited access to system properties. The application has read/write access to all system properties defined in the JNLP File, as well as read-only access to the same set of properties than an Applet has access to. 
An application is allowed to use the System.exit call. 
  

An application that needs unrestricted access to the system will need to be delivered in a set of signed JAR files. All entries in each JAR file must be signed. 
Retrieving Resources from JAR files
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. We recommend storing resources in JAR files, 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 
   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 

Security and Code Signing
Java Web Start addresses the security issues of: 
Protecting users against malicious code (intentional & unintentional) that may affect local files 
  
Protecting enterprises against code that may attempt to access or destroy data on networks 
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. Thereby allowing the user to make an informed decision whether to grant additional privileges to the downloaded code, or not. 

An application can request full access to a client system when all its JAR files are signed by including the following settings in the JNLP file: 

<security> 
   <all-permissions/> 
</security> 

The implementation of code signing in Java Web Start is based on the security API in the core Java 2 Platform. The Java 2 SE JRE 1.2.x supports code signing with the SHAwithSDA algorithm. Java 2 SE JRE 1.3 also supports MD2withRSA and MD5withRSA. The MD5withRSA is currently the most often used algorithm. 

Developers sign code for use with Java Web Start in the same manner as for Java Applets by using the standard jarsigner tool from the Java 2 SE SDK. The documentation for the jarsigner tool provides examples on how to sign code, create test certificates, and other signing related issues. 

Java Web Start also support use of the Netscape signtool when used with the Java 2 SE JRE 1.3.0. See the Netscape Web site for details: http://developer.netscape.com/software/signedobj/ 

Signing JAR Files with a Test Certificate
Here are the steps needed to sign a JAR file with a test certificate: 

Make sure that you have a JDK 1.2 or JDK 1.3 keytool and jarsigner in your path (located in the J2SE SDK bin directory). 

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 myKeystore file on disk. 

Then, create a self-signed test certificate as follows: 
keytool -selfcert -alias myself -keystore myKeystore 
This will prompt for the password. Generating the certificate takes a few minutes. 

Check to make sure that everything is ok. To list the contents of the keystore, use the 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):
C2:E9:BF:F9:D3:DF:4C:8F:3C:5F:22:9E:AF:0B:42:9D

Finally, sign the JAR file with the test certificate as follows: 
jarsigner -keystore myKeystore test.jar myself 
Repeat this step on all of your JAR files. 

Please note that a self-signed test certificate should only be used for internal testing, since it does not provide any guarantees about the identity of the user and therefore cannot be trusted. A trust-worthy certificate can be obtained from a certificate authority, such as VeriSign, and should be used when the application is put into production. 

Converting JNLP files to work with this release
The JNLP file format has changed significantly since the 0.4 early access release.  Below is a list of the most common modifications that needs to be applied to a 0.4 JNLP file to make it compatible with Java Web Start 1.0: 
Set spec attribute to 1.0. 
Rename the unrestricted element to all-permissions. 
Rename the jre element to j2se and move this element inside the resources element (i.e., make j2se a subelement of resources). 
Converting JNLP files used with the 1.0-beta or 1.0-rc release only requires updating the spec attribute to "1.0". 

Descriptions of new JNLP file features can be found below. 

JNLP File Syntax
The format used in this release correspond to the format specified in the Java Network Launching Protocol and API (JNLP) Specification, v1.0. This document describes the most commonly used elements of the JNLP file. Refer to the specification for a complete description of the format. 
The JNLP file is an XML document. The following shows a complete example of a JNLP file: 

<?xml version="1.0" encoding="utf-8"?> 
<!-- JNLP File for SwingSet2 Demo Application --> 
<jnlp 
  spec="1.0+" 
  codebase="http://javaweb.eng.com/jaws/apps" 
  href="swingset2.jnlp"> 
  <information> 
    <title>SwingSet2 Demo Application</title> 
    <vendor>Sun Microsystems, Inc.</vendor> 
    <homepage href="docs/help.html"/> 
    <description>SwingSet2 Demo Application</description> 
    <description kind="short">A demo of the capabilities of the Swing Graphical User Interface.</description> 
    <icon href="images/swingset2.jpg"/> 
    <offline-allowed/> 
  </information> 
  <security> 
      <all-permissions/> 
  </security> 
  <resources> 
    <j2se version="1.3"/> 
    <jar href="lib/SwingSet2.jar"/> 
  </resources> 
  <application-desc main-class="SwingSet2"/> 
</jnlp> 

The example shows the basic outline of the document. The root element is jnlp, which has four subelements: information, security, resources, and application-desc. In addition, Java Web Start also supports launching Applets by using the applet-desc element. The elements are described in more detail below. 

The JNLP Element
spec attribute: This attribute must be 1.0 or higher to work with this release. The default value is "1.0+". Thus, it can typically be omited. 

codebase attribute: All relative URLs specified in href attributes in the JNLP file is using this URL as a base. 

href attribute: This is a URL pointing to the location of the JNLP file itself. Java Web Start requires this attribute to be set in order for the application to be included in the Application Manager. 

The Information Element
title element: The name of the application. 
vendor element: The name of the vendor of the application. 

homepage element: Contains a single attribute, href, which is a URL locating the home page for the Application. It is used by the Application Manager to point the user to a Web page where they can find more information about the application. 

description element: A short statement about the application. Description elements are optional. The kind attribute defines how the description should be used, it can have one of the following values: 

one-line: If a reference to the application is going to appear on one row in a list or a table, this description will be used. 
short: If a reference to the application is going to be displayed in a situation where there is room for a paragraph, this description is used. 
tooltip: A description of the application intended to be used as a tooltip. 
Only one description element of each kind can be specified. A description element without a kind is used as a default value. Thus, if Java Web Start needs a description of kind short, and it is not specified in the JNLP file, then the text from the description without an attribute is used 
All descriptions contain plain text. No formatting, such as HTML tags is supported. 

icon element: Contains an HTTP URL to an image file in either GIF or JPEG format. The icons are used to represents the application when Java Web Start presents the application to the user during launch, in the Application Manager, and in desktop shortcuts. A 64x64 icon is shown during download and a 32x32 for desktop icons and in the application manager. Java Web Start automatically resizes an icon to the appropriate size.