Distributing Applets 

• Once you have finalized your applet code, the final stage in the development process will be to determine how to make your program available to browsers on the web. 
• In the last section, we showed an example of this when we created a class file, referenced it with our HTML, and sat back while web surfers played with our applet. 
• In the early days of Java this approach produced "example" applets and little ticker tape programs, but in the fast paced world of computer languages it has quickly evolved. Java is now used to produce useful applets, vital to businesses, e.g. one such applet maintains the phone list of thousands of employees for an international company. 
• Rather than simply placing raw class files on the web for download, it is likely that as your applets grow in size, you may want to utilize some of the distribution technologies now available to Java developers. Though, placing your raw class files on the web will work, it is not necessarily the most efficient way to distribute your applet. 
• As you will know if you have spent any time web surfing or playing with Java applet demos, the Internet's biggest bottleneck is the speed of the slowest link in a connection. Although the so-called back bones of the Internet might exchange data at massive rates, most people web browsing, do so with a modem. That's very slow. In fact, it is so slow that it is very possible that if your applet takes too long to download, potential clients will simply surf-on and ignore your dour looking gray square box page. You will never even get to show off all your hard work. 
• Perhaps we should take a moment to get some perspective on this problem. How slow is slow? 
• Let's assume that the average viewer of your page will be using a 14.4 modem. Though this may not be the typical modem speed used by the average web programmer, it is actually a fairly realistic assumption about the average web surfer and probably will be for at least a couple more years. With their 14.4 modems, your viewers can expect it to take 1 second per kilobyte to transfer. This means that 60k worth of class files would take a minute to download. What's worse, you must also factor in the time it takes for their web browser to start the virtual machine and instantiate your applet. Most people have enough patience for about 5 seconds. You get the picture. 
• Traditionally, Java has addressed the speed bottleneck by attempting to be an amazingly small language. Further, developments in the JDK have been slowly incorporated into the main web browsers so that the majority of the class files your applets will need will already be resident on the client's machine. 
• However, until recently, there were no great ways to address the size of your own code, or the class libraries that you use. Fortunately, recent developments in archiving and compression technologies have given developers excellent ways to make their large applet code much more modem-friendly. 
• But wait! Is it necessarily better to use one of these flashy, new distribution technologies if you have a large application? Well, unfortunately, there are no easy answers because it depends on the specifics of your situation. Consider the following scenarios: 


The Deadweight Scenario

• Suppose you have a large application with dozens of class files. However, because of the average work flow of your application, it is unlikely that the user will need all of the functionality in any one usage. Thus, many of the classes that are part of the application will be deadweight in any given execution. 
• So, given that situation, if you archive the application and force the user to download the entire bundle at once, you may be forcing them to download more class files than they need to. Even considering the fact that you may have compressed those class files, the deadweight of the extraneous classes could counter the benefits of compression or even end up making the final download time longer than it needs to be. 
• In this case, archiving or even archiving with compression may not be your best option. 


Thin Button and Progress Bar Scenario

• Suppose again that you have a large applet and your users are webbing away from your page before they get a chance to see the applet because it takes so long to download. You think to yourself that an ideal resolution would be to place a very lightweight push button that the user could press to begin the application. When a user presses the button, you continue to imagine, a progress bar could popup and let the user know that the applet is loading by filling up proportionally to the number of class files downloaded. 
• Thinking that is a good solution you add something like the following to your code:

try {
Class C = Class.forName("myClass1");
thinButton.setLabel("Loading...20%");
thinButton.repaint();

C = Class.forName("myClass2");
thinButton.setLabel("Loading...40%");
thinButton.repaint();

C = Class.forName("myClass3");
thinButton.setLabel("Loading...60%");
thinButton.repaint();

C = Class.forName("myClass4");
thinButton.setLabel("Loading...80%");
thinButton.repaint();
        }
catch (ClassNotFoundException e)
        {
        System.out.println("Class not found exception");
        }

• The lightweight button would solve the problem of the applet taking too long to download and the progress bar would be a psychological crutch which would help the user through the download time. But again, this would be impossible if you downloaded the entire application as an archive because by the time the light weight button was instantiated, the entire class library would have been downloaded. 


Web Server Twiddling Its Thumbs Scenario

• One of the "official" benefits of archiving is that a web browser need only make one HTTP request from a web server in order to download an applet. This saves the web browser from having to open separate HTTP connections for each class file, image and data file in your program. 
• Thus, if you have two dozen files in your applet, you would reduce the number of necessary HTTP connections by 11. Wow, 11 times faster! 
• Well, not exactly. In actuality, the time it takes to make an HTTP connections is minimal. In fact, the more connections you open the better it is for you. After all, if the web browser multi-tasks by downloading class files in tandem, it can download the class files even faster. 
• So why archive (besides compression if it is available)? 
• The "real" danger of multiple connections is that if everyone multi-tasks, we may end up with some pretty nasty traffic jams on the I-way. 
• Further, the more HTTP requests that you hit a web server with, the busier it becomes. If two people download a 12-file applet that is archived, the web server must juggle two requests. If, on the other hand, the web server has to distribute the 12-file un-archived applet, it has to juggle 24 requests. As you can imagine, this could bog down a web server pretty quickly. 
• So the official word is that you should always archive. In a sense, archiving is more a courtesy than a performance boost. By archiving you are doing your little part to reduce the total traffic on the net. And in exchange you agree to accept some slowdown in your own work. 
• Well, as it so happens, and as you might expect, very few people are courteous on the net. In fact, in terms of the number of HTTP connections, Netscape and Internet Explorer have had well-publicized speed wars throughout the last few years in which they ruthlessly opened up connection after connection in order to boast their marketing superiority over the other. "We're faster!" "No, we're faster!" Faster at what cost? 
• And as for the benefits of slamming servers with multiple HTTP requests, because of web server time slicing, applets that demand 12 HTTP requests get a higher priority over those that demand only one connection. 
• So what is a web designer to do? 
• From a selfish perspective, it is better to multi-task. The designer must ask, "why should I be courteous and in the process, be less competitive"?
• Courtesy and morality are up to you, however we would suggest that you at least consider the load on the web server you are using. If your web server is relatively unused, feel more free to demand more of its attention. However, if your applet is hosted on a public ISP, try to keep the other users on the system in mind. Also, carefully balance the time savings that you gain from multi-tasking. Clearly, the time saved for multi-tasking a 3-file applet does not necessarily justify the network traffic and server load you cause. 


The Final Word

• As you can see, deciding how to distribute your applet can be a challenging design decision in itself. However, regardless of what you choose in any given case, it will be necessary for you to have at your disposal an array of tools for distribution. This chapter will discuss the process of distribution to give you a more detailed look at the available technologies to make distributing your applet faster and more efficient. 

Additional Resources:

• Learning to Write Java 
• Introducing Java (TM) - Your First Applet 
• Java FAQs 
• Java Software 
• java.sun.com 
• Sun Microsystems

Writing Applets
Table of Contents
Distribution History