Reduce the launch time of your applets: Store them on client machines

Tired of those slow applet downloads? Here's how to speed things up!

Launching a Java applet over a dial-up Internet connection can take tens of seconds or even minutes. While there are many things an applet designer can do to deal with this problem (see Resources), the sheer number of bytes that must be downloaded provides an upper limit on how fast any given applet can launch. One solution is to rewrite your applet as a Netscape plug-in. Unfortunately, this means you must support different binary versions of your plug-in for different machine architectures. Another approach is to write an applet in Java but store that applet on your clients' machines, much like a Netscape plug-in. With this approach, you retain most of Java's "write once, run anywhere" benefits, while getting most of the speed benefits of a plug-in.

This article shows you how to store your applets on client machines. It covers clients that aren't running Java, clients that have Java but don't have your applet installed on their machine, and clients that already have your applet on their machine. It also explains how to keep your applets from colliding with applets that other authors have stored on your client's machine, and addresses versioning problems. Finally, it discusses the security aspect of loading applets from a hard drive instead of over the network, covering when you should and shouldn't use this technique.

The three types of clients

In order to store your applets on client machines, you must support three types of clients:

  1. Clients running non-Java-enabled Web browsers or Java-enabled browsers that have Java disabled.

  2. Clients running Java-enabled browsers that do not have your applet loaded on their hard drive.

  3. Clients running Java-enabled browsers that have your applet loaded on their hard drive.

Clients without Java

Some of your users will be running non-Java-aware browsers or will be running Java-aware browsers with Java disabled. Without Java support they won't even know that an applet is present. To support these users, you must place text within the applet tags so that your users know something is there. The bold text in the example below demonstrates this support.

<APPLET CODE = "MyApplet.class" WIDTH=200 HEIGHT=100>

<PARAM NAME = datafile value = "data.txt">

There is a Java applet here. To use it, you need a Java aware

browser with Java enabled.

</APPLET>

HTML Example

Clients without your applet

For users with Java, your applet must detect whether the client machine has your applet loaded on its hard drive. Unfortunately, Java applets are not permitted to explicitly read to or write from the hard drive of a client machine. However, applets are permitted to use the built-in Java class loader to load classes by name. You can use this class loader to determine if your applet is installed on a client's machine by attempting to load a class that is only stored on the client's machine, not on your server. If the load succeeds, then your applet is installed. If it fails, it isn't. You will need a configuration class later (see Versioning), so use this class. The code looks like this:

class MyApplet extends Applet { private boolean isLoaded() { boolean result = false;

try { Class.forName("Configuration"); result = true; } catch (Exception e) { }

return result; } }

Listing 1: isLoaded() example from MyApplet.java

If the client machine does not have your applet loaded, you can give the user the option of either downloading the applet to their hard drive or running it from the Web server.

Unfortunately, because Java does not allow applets to write to the client's hard drive, the client must download and install the applet manually. Your site must have a page devoted to this process including clear instructions.

Clients with your applet

If the client machine already has your applet loaded on it, everything will work fine. If a Java class file exists on your client's machine and also on your Web server, the Java run time in both Netscape Navigator 3.x and Microsoft Internet Explorer 3.x loads the class file on the client's machine (this is reasonable, since it prevents users from overriding the built-in classes). This behavior allows casual users who don't want to put your applet on their hard drive to run your applet, while also allowing users who do put your applet on their hard drive to benefit from the faster load speed.

Where to install your applet on your client's machine

Both Navigator and Internet Explorer have a directory for Java class files, as shown in the table below. Java class files can be copied into these directories, and then your applets can use them. In fact, anyone's applet can use them. Installing your applet on a client's hard drive is as simple as getting the client to copy your class files into the appropriate directory for their machine and browser.

Browser
Directory
Netscape Navigator 3.x for Windows NT/95The Netscape Navigator directory\Program\Java\Classes
Netscape Navigator 3.x for MacintoshThe Netscape Navigator directory/Java/netscape-classes
Netscape Navigator 3.x for UnixThis doesn't work on Netscape for Unix. I don't know why not.
Internet Explorer 3.x for Windows NTC:\Winnt\Program\Java\Classes
Internet Explorer 3.x for Windows 95C:\Windows\Java\Classes

Notice that this technique does not work for Netscape on Unix (at least not on Solaris for SPARC). This will be a minor or major drawback depending on what your client base looks like.

UPDATE:

Several readers with access to Unix machines wrote to tell me how to make this work on Unix (the first to write was Scott Spencer). All you have to do is add:

The Netscape Navigator Directory/classes

to your CLASSPATH environment variable. Your Netscape Navigator directory will probably look somethink like:

/home/mark/.netscape/

So what you'll need to add to your CLASSPATH will look like:

/home/mark/.netscape/classes

Thanks to all those who wrote.

Which files go where?

It is important to copy most of your applet's files to the user's hard drive. It is just as important not to copy

some

of your applet's files to the user's hard drive. It is also important to have one file exist

only

on the client's hard drive and not be accessible from your server by the Java run time. This table shows which files go where:

FileClient MachineServer
MyApplet.class
No
Yes
AppletRunner.class
No
Yes
InstallDialog.class
No
Yes
UpdateDialog.class
No
Yes
Configuration.class
Yes
No
your other class files
Yes
Yes

The MyApplet class is the class embedded in the APPLET tag:

<APPLET CODE = "MyApplet.class" WIDTH=200 HEIGHT=100>

<PARAM NAME = datafile value = "data.txt">

There is a Java applet here. To use it, you need a Java aware

browser with Java enabled.

</APPLET>

Extract from Example.html

The MyApplet, AppletRunner, InstallDialog, and UpdateDialog classes support the installation of your applet on client machines.

You do not want your MyApplet class on the client's hard drive because if it's there you cannot update its behavior. The Java run time searches for each class file it needs first on the local machine. Only if a particular class file cannot be found on the local machine does the Java run time ask the server for that particular class file. This means any class file found on the client machine takes precedence over an identical class file on the server. You want the ability to change the behavior of your MyApplet class, so you cannot permit MyApplet to be loaded on the client's machine.

You would like the AppletRunner, InstallDialog, and UpdateDialog classes on your client's hard drive, but there isn't a good place on that hard drive to put them. It is much safer to leave them only on your server.

You want the Configuration class file to exist on the client's hard drive and not on the server because this is the file you use to determine whether the applet is loaded onto the client's hard drive. If the Configuration class file is on the server, your applet won't be able to tell if it is installed on the client machine or not.

The remaining class files are allowed on both the server and the client machines. Storing the class files on the client's machine allows clients who have installed the applet to load quickly. Storing the class files on the server allows clients that do not wish to install the applet on their hard drives to run it over the network.

Namespace problems: Don't collide with others

You

could

put all your class files in the appropriate "Classes" directories on your client's machine, but this is a bad idea. Doing this clutters up the client's directory structure and makes it difficult to uninstall your applet (disk space is cheap, but it isn't free). Much worse, this approach puts your class files at risk, as they can be overwritten by other applets that are also being stored on the client's machine. (This is the reason you don't store

AppletRunner

,

InstallDialog

, and

UpdateDialog

on the client machine. They would have to go in the "Classes" directory.)

To avoid collisions with other applets installed on the client's machine, use Java's "package" feature. You can put most of your applet into a package. You must then store the class files in a subdirectory with the same name as the package.

Installing the applet onto the client's machine consists of only two steps:

  1. Creating a directory with the correct name in the appropriate Java class directory on the user's machine.

  2. Downloading from the server the appropriate class files and placing them in the newly created directory. If there are a large number of class files (and there probably are, or you wouldn't need to install them on a client's machine), this step might be simplified by having the user download a single compressed file (PK-ZIP, tar, or whatever) and then uncompressing it in the correct directory. If you choose to do this, you must also make available an appropriate uncompressing tool for each platform you intend to support.

Versioning: Don't collide with yourself

Many useful applets will take some data file from the server and perform actions based on that file. For example, an applet designed to display pictures using a new graphic format (such as some fractal algorithm with high compression) would take as a parameter the name of a file with a picture to be displayed. Over time, the data files that your applet processes can get more complex, and your applet will get updated to version 2 and then 3.

This can cause a problem if your client's machine has installed on it version 1 of your applet and you need version 2 to process the data file (in our example, the file containing the graphic). You can deal with this problem by versioning your applet and checking the version for compatibility before it runs.

The version information in the Configuration class allows this problem to be detected and dealt with:

class Configuration
{
    int getVersionNumber()
    {
        // This is an example version number.
        return 2;
    }
}

The MyApplet class is responsible for dealing with version incompatibilities. Depending on the nature of the incompatibility, you can prompt the user to upgrade to the most current version. Additionally, you can give the user the option of using an older version if the newer version adds performance improvements but not new features. Even if the new version adds new features, if this particular instance of the applet does not use these features, then you might allow the user to run using the older version of the applet.

Security risks

One of the features of Java that allows it to run securely over networks is the built-in security model. Each class file is checked by the bytecode verifier; class files that cannot be verified as safe are rejected. One concern is that classes loaded from the client's hard drive might escape this verification. Fortunately, they do not escape verification.

Netscape Navigator and Microsoft Internet Explorer both check class files in their "Java/Classes" directory just like class files loaded over the network -- well, not exactly, but the differences are minor. This means a client machine loading class files from a local hard drive is at little more risk than a client machine loading classes over the network.

Internet Explorer has two other directories under "Java" and at the same level as the "Classes" directory: "Lib" and "TrustedLib." Java class files placed in the "Lib" directory also will be used by the Java run time. (I don't know what happens if class files with identical names are found under both "Classes" and "Lib.") Class files loaded from "Lib" are checked just like class files loaded from "Classes" or over the network. Java class files placed in the "TrustedLib" directory are not used by the Java run time. There is an uncompressed file, tclasses.zip, stored using the PK-ZIP file format in the "TrustedLib" directory. tclasses.zip contains class files. I don't know what happens when class files are added to tclasses.zip.

When to consider installing applets on client machines

You should install applets on client machines in the following cases:

  • When you would write a plug-in anyway
  • To support other programming languages
  • For applets to which you expect visitors to return
  • For large applets on intranets

Let's look at each of these cases in detail.

When you would write a plug-in anyway

1 2 Page 1