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!

Page 2 of 2

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:

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.

Mark Roulo has been programming using C and C++ for the past seven years. He has been using Java for the last two years and is implementing an ANS-compliant Forth interpreter in Java. His main programming interests are portable, distributed, concurrent software as well as software engineering.

Learn more about this topic

| 1 2 Page 2