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

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.

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.

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:

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

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

The big advantage plug-ins have over applets is that the plug-in resides on the client’s hard drive and need not be downloaded each time it runs. By storing applets on the client’s machine, almost all existing Netscape plug-ins are candidates for rewriting in Java.

Many existing Netscape plug-ins support only Windows NT and 95 on an Intel x86 machine — the so-called “Wintel” platform. Others support only Wintel and Macintosh. Most plug-ins are not supported on all the platforms on which Netscape Navigator itself runs.

Rewriting a plug-in that is supported on Unix will not make much sense, but rewriting a plug-in that is only supported on Wintel or on the Macintosh might. The non-Wintel, non-Macintosh users can still use the Java version even if they have to load it over the network. Additionally, in the future, Netscape may allow Unix versions of Netscape to function the same way the Windows and Macintosh versions do. If so, Unix users will be able to install your Java applet on their machines too.

Finally, while rewriting a plug-in in Java does not completely avoid the portability problem, it makes it much more tractable than native mode plug-ins.

To support other programming languages

Java is a fine language for general-purpose programming. It supports both the procedural and object-oriented programming styles. However, other programming languages and programming styles do exist. For many programming problems, the Java language is not the best tool for the job. It would be nice to be able to write applets using other languages and still get the cross-platform portability provided by the Java virtual machine.

Unfortunately, while it is possible to write applets in other languages, many languages get much of their power from their runtime library. Common Lisp, for example, comes with about 1,000 built-in functions. Prolog comes with a built-in inference engine. An applet written in either Lisp or Prolog would be impractical because of the huge latency imposed by downloading the runtime engines and libraries. If the Lisp or Prolog engines and runtime libraries were stored on the client’s machine (just like the Java language runtime library is), applets written in Lisp or Prolog would become practical.

For applets to which you expect visitors to return

Any applet to which you expect visitors to return is a candidate for being stored on the client’s machine. Your server benefits because some of the bandwidth that would have been used to download the applet is freed up. Your client benefits because the applet launches faster. The Internet community benefits, too, from the freed-up bandwidth.

This does not mean any applet for which you expect return traffic should be stored on client machines. For small applets, there may be no real benefit. It may be that your clients won’t store your applet on their machine even if they can. Applets for repeat visitors are candidates for storage on client machines, but not all of them should be written to allow this.

For large applets on intranets

Small applets on intranets should just be left as normal applets. The added complexity of storing them on client machines is not worth the time saved when the network connection is 10 Mbps or faster.

Large applets on an intranet, however, are candidates for storage on client machines. Not only will the applet launch faster, but storing it on client machines will help keep the network from bogging down.

When storing applets on client machines is not appropriate

If your applet is small, there is no point in adding the extra complexity of storing it on client machines.

If you need every last clock cycle of speed out of your plug-in, then Java is not appropriate.

If you need to use the client’s hard drive or make some other use of the client’s machine not permitted by the Java runtime “sandbox,” then Java is not appropriate (see Resources). A good example of this is Adobe’s Acrobat PDF viewer product. One of its functions is printing the document being viewed. You can’t do this with a Java applet.

Example

Here is an

example

of an applet that is installable on a client’s hard drive.

Note: Keep in mind that the “Load Applet” button on the example above will not function because, as stated earlier, Java applets are not permitted to explicitly read to or write from the hard drive of a client machine.

Sample code

Here is sample code for the example applet. It is presented in two different ways:

• As an installable applet
• As a normal applet

Miscellaneous notes

• Netscape Navigator 4.0 will give the user the option of allowing specific applets access to machine services outside the Java “sandbox.” This points to an obvious improvement in the installation process: ask the user for permission and then let the applet download itself onto the client’s hard drive. This makes life much easier for the user.

• Another obvious improvement would be to write a Netscape plug-in that installed class files onto a client’s hard drive.

• Marimba produces a product called Castanet that allows for version controlled installs over a network. (For a link to the company’s Web site, see Resources.)

Conclusion

Storing Java applets on client machines provides the benefits of Java’s “write once, run anywhere” while avoiding a major drawback to most Java applets which is long download times. While not always able to replace Netscape plug-ins, applets stored on client’s machines provide a reasonable alternative to Netscape plug-ins.