APPENDIX

B   An Overview of Java Web Start

As mentioned in Chapter 1, with the release of JDK 9 applets are no longer recommended for the development of web-based applications. Although applets served Java well for many years, they rely on a browser plug-in, and support for the Java browser plug-in has been eroding. For this and other reasons, the use of Java Web Start is now recommended for the deployment of web-based programs. The key advantage of Java Web Start is that no browser plug-in is required. Thus, an application deployed via Java Web Start can run independently of the browser.

It is important to state at the outset that the subject of Java Web Start, and deployment strategies in general, is quite large. Furthermore, Java Web Start relies on many other deployment-related features, such as JAR files, manifest files, application signing, and JNLP files. Additionally, there are several other considerations relating to the deployment of commercial applications. Normally, a discussion of deployment would be outside the scope of this book. However, because of the increased importance of Java Web Start, a brief discussion that introduces several of its key aspects is included here. The goal is to give you a general sense of how Java Web Start works. As you advance in your Java programming career, you will want to study Java Web Start in detail.

NOTE Because deployment of Java applications is subject to change and/or enhancement, especially as it relates to security issues, it is strongly recommended that you consult the Oracle documentation pertaining to deployment for the latest information. Also, the following discussion assumes an environment that supports a modern version of Java.

What Is Java Web Start?

At its core, Java Web Start is a mechanism that supports the web-based deployment of Java applications. Unlike a Java applet, which must extend either the Applet or JApplet class and support the general applet architecture by supplying the init( ), start( ), stop( ), and destroy( ) methods, Java Web Start applications are “normal,” client-based programs, such as those shown in the Swing and JavaFX chapters of this book. In other words, a Java Web Start application is essentially a rich client application that is downloaded and executed from the Web. For example, a program such as JListDemo in the Swing chapter can be run as a Java Web Start application with no changes whatsoever.

Because Java Web Start does not use a browser plug-in, a Java Web Start application requires that only the JRE be installed on the host computer. This eliminates the problem with missing, disabled, or out-of-date plug-ins. Because the Java Web Start application runs on the desktop (not within the browser), your program will look and feel like a “normal” application on the host. Furthermore, once a Java Web Start application has been downloaded, it is possible to execute it offline. It is also possible to create a shortcut to the application. Frankly, Java Web Start offers the application developer the ability to create applications whose functionality exceeds what would have normally been appropriate or feasible for an applet.

By default, Java Web Start applications run in the same security “sandbox” used by unsigned applets, and thus have the same restrictions. So by default, Java Web Start applications provide security protections similar to that of unsigned applets. It is possible, however, to give a Java Web Start application additional security permissions, if required.

Four Key Java Web Start Essentials

Although there are many features, techniques, and nuances associated with deploying an application using Java Web Start, there are four essential elements. First, a Java Web Start application must be packaged in a JAR file. Second, the JAR file should be signed. Third, a JNLP file must be created that specifies the application’s launch information. Finally, typically you will create a link to the JNLP file that launches the application. Each is briefly described here.

Java Web Start Apps Require a JAR File

All Java Web Start applications must be packaged in a JAR file. As explained earlier in this book, JAR stands for Java ARchive. A JAR file is created by use of the jar command-line tool. When creating a JAR file for Java Web Start, you will specify all of the files, such as classes and resources, used by the application, and information to include in the application’s manifest. The manifest contains information about the JAR files, including the security setting.

The jar tool supports many options, but for simple applications, you will only need to use three. They are c, f, and m. The c option tells jar to create an archive, f specifies the name of the archive, and m tells jar to include the information in the specified manifest file. For example, the following command line creates a JAR file called MyJar.jar that contains the class in MyClass.class and includes the manifest information specified by MyMan.txt.

Notice that each filename is specified in the same order as the option list.

Java Web Start Apps Are Signed

In general, a Java Web Start app must be signed using a valid certificate. This is done by signing the application’s JAR file. In simplified terms, signing identifies the owner of an application. It also helps to ensure the integrity of the files associated with the application because the signed JAR file will be invalid if it has been changed after it is signed. The certificate must be obtained from a legitimate, third-party certificate authority. Typically, such certificates are not free and must be purchased.

Before moving on, it is important to mention a special type of certificate referred to as “self-signed.” A “self-signed” certificate is simply a certificate created by you instead of being obtained from a certificate authority. At the time of this writing, it is possible to sign a Java Web Start application using a self-signed certificate. It is important to understand that for modern versions of Java, a self-signed application will be prevented from executing unless it is explicitly specified in the Exception Site List in the Java Control Panel. Even then, you will still see a security prompt when you try to run the application. As a result, a self-signed application should not be used for deployment. This is especially true for commercial applications. Remember, all commercial Java Web Start applications must be signed with a valid, recognized certificate. That said, in some cases self-signing can be helpful when learning about Java Web Start or when developing and debugging Java Web Start applications.

To sign JAR files you will use the jarsigner command-line tool. Before you can use jarsigner, you need to have a certificate. As just explained, for general deployment, especially for commercial code, you must use a certificate from a third-party certificate authority. However, when learning or experimenting, you can obtain a self-signed certificate by use of the keytool command-line tool. In Java, digital signatures are based on the public/private key security mechanism. The keytool works with a keystore file that holds the keys and manages certificates. The example shown later in this appendix demonstrates the use of both jarsigner and keytool to self-sign the sample application.

NOTE At the time of this writing, it is technically possible to use an unsigned JAR file with Java Web Start if the JNLP file is included in the Exception Site List of the Java Control Panel. Of course, deploying an unsigned application is, in the strongest possible terms, not advised.

Java Web Start Relies on JNLP

A Java Web Start application is launched by use of a JNLP file. JNLP stands for Java Network Launch Protocol. A JNLP file is an XML file that uses the jnlp element and has the .jnlp extension. Within the jnlp element, the deployment needs of a Java Web Start application are described. Although the jnlp element supports many options, for simple applications you will need to use only a few. For example, you will typically need to specify a description of the application, the resources that it uses, and information about the application. For instance, here is a simple JNLP file that launches the Swing JLisDemo program from Chapter 32.

Let’s take a close look at the contents of this file. The file begins by specifying the minimal XML version and the UTF encoding. While not required, this is the recommended procedure. The values shown here are common, but you can adjust them as required based on the needs of your specific application. Inside the jnlp element, the href attribute specifies this JNLP file’s name. The minimum JNLP version number is specified by the spec attribute. In this example, 6.0 or greater is indicated. The version can be changed to fit your needs.

The application is described by application-desc. Notice that it identifies the main class of the application with the main-class attribute. The resources for the application are specified by resources. In this example, the JAR file for the application is indicated with the jar element. The minimum version of Java required to execute the application is specified by the java element. (In JNLP versions prior to 6, this element is called j2se and this name is still allowed.) Here, Java 8 is specified as the minimum version, but this can be changed to best fit the requirements of your application. In general, you should use the lowest version number that will work with your application.

Information pertaining to the application is contained in the information element. Here, the name and vendor of the application are specified. Also note that the application can be run offline because the offline-allowed element is included. Offline execution is especially useful for stand-alone programs that do not require Internet access to run.

It is important to state that the JNLP element supports more options and attributes than shown here. You will want to explore them in detail. Precisely tailoring the JNLP file for your application produces the best user experience.

One last point: Although a JNLP file is used to launch an application from within a browser, the application runs outside the browser. Thus, using JNLP to launch an application eliminates the need for the Java browser plug-in. This is one of the primary benefits of Java Web Start.

Linking to the Java Web Start JNLP File

In general, you will provide a link in a web page that launches the application. Here is a very simple one:

Here, jnlp-path specifies the path to the JNLP file for the application that you want to launch. Replace jnlp-path with the actual path to your JNLP file. When this link is clicked, the browser is redirected to the specified JNLP file and Java Web Start is used to launch the program. The program will run on the desktop, as explained earlier. Thus, you can leave the page the link is on, and the program remains active until you close it.

Experimenting with Java Web Start Using the Local File System

In this section we will develop a simple Java Web Start example that you can try. As explained earlier, Java Web Start applications are normally downloaded from the network. However, assuming that your browser enables you to open a file, it is possible to experiment with Java Web Start by running the application from the local file system. Doing so gives you an easy way to see how Java Web Start works without having to use a web server. It also lets you run an application in much the same way that a user of your program will, by clicking on a link on a web page.

As mentioned earlier, applications deployed by Java Web Start are, essentially, normal Java applications. Thus, Swing and JavaFX programs can be used with Java Web Start. In this example, we will use the JavaFX ToggleButtonDemo program shown in Chapter 35. Although the process involves several steps, once you have worked through the procedure you will have a better idea of how Java Web Start works.

Here are the steps that you will follow to create and deploy ToggleButtonDemo from a file on your machine.

1.  Create a JAR file for ToggleButtonDemo called ToggleButtonDemo.jar.

2.  Create a keystore that contains a self-signed certificate and sign ToggleButtonDemo.jar.

3.  Create a JNLP file called ToggleButtonDemo.jnlp that describes and launches ToggleButtonDemo.

4.  Create a short HTML file called StartTBD.html that contains a link to ToggleButtonDemo.jnlp.

5.  Add ToggleButtonDemo.jnlp to the Exception Site List in the Java Control Panel.

6.  In your browser, open StartTBD.html and then click on the link. After a security check, ToggleButtonDemo will execute on the desktop (not in the browser, the way applets do).

The following sections walk through these steps in detail.

Before we begin, it is important to point out that not all of these steps are necessarily required to run a Java Web Start application from the local file system. For example, at the time of this writing self-signing an application provides no benefit. Self-signing is included here simply as a way to demonstrate signing a JAR file. Also, an HTML file may not be technically required because it may be possible to execute the JNLP file directly. All steps are shown, however, because they help provide insight into the process. Furthermore, in the future, additional steps or a modified procedure may be required.

Create a JAR File for ToggleButtonDemo

First, if you have not already done so, using the code shown in Chapter 35, compile ToggleButtonDemo.java. This will create two class files: ToggleButtonDemo.class and ToggleButtonDemo$1.class. The first contains the main class of the application. The second contains the anonymous inner class used by the action event handler. Both of these classes are required by the application. As such, both will need to be included in the application’s JAR file.

To create the JAR file for an application, you will use the jar command. Here is the form we will use for the ToggleButtonDemo program:

Here, the option c tells jar to create a JAR file. The f option specifies the name of the file, which is ToggleButtonDemo.jar in this case. The m option causes the information in MyMan.txt to be included in the manifest information associated with the JAR file.

A JAR file’s manifest contains information related to the file. All JAR files have a manifest, and the m option causes the information in the specified text file to be added to it. For ToggleButtonDemo, create the following file called MyMan.txt:

This specifies that the main class of the program is ToggleButtonDemo and that execution of the program is restricted to the sandbox, which is Java’s most restrictive setting. This setting must match that specified by the application’s JNLP file, which is sandbox by default.

Create a Keystore and Sign ToggleButtonDemo.jar

For all modern versions of Java, a Java Web Start application must be signed with a valid security certificate. A certificate identifies the owner of the application, and signing helps to ensure the integrity of its JAR file. In Java, certificates are based on a public/private key security mechanism. The keys are stored in a special file called a keystore. Before you can sign an application, you need to create a keystore that contains a certificate. Keystores and certificates are managed by using keytool, which is provided with the JDK.

As explained earlier, for general deployment, you will need a certificate obtained from a legitimate third-party certificate authority. However, you can gain insight into the signing process by using a self-signed certificate. Remember, a self-signed application is not suitable for distribution because it will cause a security prompt that discourages the use of your application. It also may be blocked completely. However, using a self-signed certificate gives you an easy, cost-free way to see JAR signing in action.

As you might expect, keytool supports a number of options, but only a few are needed for the purposes of this example. Here is one approach you can use:

Here, genkeypair tells keytool to generate a new key pair and to create a self-signed certificate with that pair. The name you specify after the alias option, in this case devName, identifies the entry in the keystore. The name of the keystore is specified by keystore and is devKeys in this case.

After you enter this command, you will be prompted for the following information: a password, your name, the name of your organizational unit, the name of the organization, the city, the state, and a country code (which for the United States is US). This command then automatically creates a self-signed certificate using information you specified. Be sure to remember the password because it will be needed by the next step.

NOTE Versions of keytool prior to Java 6 required the use of the -selfcert option to generate a self-signed certificate.

Now that you have a certificate, you can use jarsigner to sign ToggleButtonDemo.jar. This tool also supports many options, but for this example only one is needed. It specifies the keystore:

Here, the keystore option specifies the keystore file, which is devKeys in this example. This is followed by the name of the JAR file to sign, which is ToggleButtonDemo.jar. Finally, the certificate alias is specified. When you execute this command, you will be prompted for the password you specified in the previous step. Understand that any time you change the ToggleButtonDemo.jar file, it must be re-signed.

REMEMBER Although self-signing is helpful when demonstrating the JAR signing procedure, a self-signed certificate must not be used for actual application deployment. A certificate obtained from a valid certificate authority is required. Furthermore, a self-signed application that you did not create constitutes a security risk. Therefore, as a general rule, you should exercise great caution before attempting to run self-signed applications that you did not create.

Create a JNLP File for ToggleButtonDemo

The next step is to create a JNLP file that will launch ToggleButtonDemo. Here is the one shown earlier. Although it is very simple, it is sufficient for this example. Call this file ToggleButtonDemo.jnlp.

Create a Short HTML File Called StartTBD.html

Although it is often possible to use a JNLP file directly from the Web, usually a link is provided to launch the application. Here is a very simple one for ToggleButtonDemo:

Call this file StartTBD.html. When you click on the link, the browser is redirected to ToggleButtonDemo.jnlp and Java Web Start is used to launch the program. It will run on the desktop, as explained earlier. Thus, you can leave the page the link is on, and the program remains active until you close it.

Add ToggleButtonDemo.jnlp to the Exception Site List in the Java Control Panel

Because ToggleButtonDemo.jar was self-signed, and because it will be executed from the local file system, you will need to add the URL of ToggleButtonDemo.jnlp to the Exception Site List maintained by the Java Control Panel. (The Exception Site List was added to Java in Java 7, update 51.) Assuming that ToggleButtonDemo.jnlp is contained in the C:JavaMyDevFiles directory, you would add the following to the Exception Site List:

Here, FILE: denotes a file on the local file system. For normal deployment, you would specify a network address.

NOTE As a general rule, a URL in the Exception Site List that uses the FILE: prefix (i.e., one that refers to a file on the local file system) constitutes a security risk. Therefore, you should use great caution before adding such a URL to the Exception Site List for programs that you did not create.

Execute ToggleButtonDemo via Your Browser

At this point, you can launch ToggleButtonDemo from your browser. To do so, open the ToggleButtonDemo.html file in your browser. For example, in Internet Explorer, use the Open option in the File menu. (As mentioned at the start of this section, this example requires that your browser allows you to open a file on the local file system.) Once the file is displayed, click the Launch ToggleButtonDemo App link. Even though you have added ToggleButtonDemo.jnlp to the Exception Site List, you may still receive a security prompt the first time you run the program. After responding to a security prompt, ToggleButtonDemo will run. It will look exactly like it does when run normally from the command line, as you did in Chapter 35.

NOTE Remember, executing a Java Web Start application from a file on the local file system and using a self-signed certificate are for development, debugging, experimenting, and learning purposes only. For actual deployment, a certificate from a recognized authority is required, and the application will be deployed via the network.

Running a Java Web Start Application Using javaws

When developing Java Web Start applications, it is not necessary to use a browser to run your application. Instead, you can use the javaws tool to run the application directly from the command line. Simply specify the name of the JNLP file. For example, assuming that ToggleButtonDemo.jnlp and ToggleButtonDemo.jar are in your current working directory, then:

causes the ToggleButtonDemo program to be executed without the use of a browser or an HTML file. This can enable faster compile/test/debug cycles. Of course, security requirements will apply.

Using Java Web Start with an Applet

Although applets are being phased out, they are currently still supported by Java Web Start and can be run by a JNLP file. You may see this approach in legacy code. The element that describes an applet is called applet-desc. When updating older code you should rework an applet into an application and specify it with application-desc, as used earlier.