Articles : JavaBoutique's Introduction to Java :
Distributing Applets :

3 Scenarios

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:

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.

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.

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.

NEXT

Selena Sol contributes to the JavaBoutique's Introduction to Java. Selena curently works for Barclays Capital in London, one of the leading global investment banks in Europe and has worked as a software developer for the National Center for Human Genome research, Microline Software, Neuron Data, and Electric Eye in Singapore. Selena is perhaps best-known for creating the Public Domain Web Script Archive (Extropia) and writing several books on Web Programming (Perl, CGI, Java).
Email: selena@extropia.com