CHAPTER 12 - Deployment

Deployment is a critical part of the development of your program. Choices you make about deployment may have little or no effect on your code, but can have a large impact on the perceived performance of your product. Your deployment choices are especially important for network-based applets and applications. The speed at which your program is downloaded and displayed is important to users, and can be very dependent on your deployment strategy.

This chapter discusses several ways to reduce the download time of network-based (intranet and Internet) applications, including the use of javac compiler options, Java Archive (JAR) files, commercial packaging utilities, and more.

12.1 Compiler Options

One fairly easy way to reduce download size of your program is to use the javac -g:none option when compiling the final version of your program. This strips all debugging information from the class files. Running a quick test with the Metalworks JFC demo (included in the SDK) shows about a 13 percent reduction in class file size by using this option, as shown in Table 12-1. Using the

-g:none

option also results in a slight reduction in RAM footprint.

The downside is that if your customers experience problems in the field, the problems can be slightly harder to debug. For example, stack traces from exceptions won't contain line numbers.

Total Size of Class Files

javac *.java

javac -g:none*.java

46K

40K

*Total Size of Class Files*
*javac .java**	*javac -g:none.java**
46K	40K

12.2 JAR Files

JDK 1.1 introduced the concept of a JAR file. JAR files condense a number of class files (and other resources like GIF files) into one simple-to-deploy package. The JAR file format is based on the popular zip algorithm and provides compression as well as convenience. Putting your classes and resources into a JAR file can considerably decrease the overall number of bytes clients need to download in order to use your application. JAR files can also improve the start-up speed of applets downloaded from web servers by a far larger amount than the reduction in download size would imply.

12.2.1 Reducing Program Size

Table 12-2 shows the savings when the Metalworks JFC demo is saved in a JAR file. The complete uncompressed, unoptimized demo (both classes and resources) occupies 61K. When it's built without debug information, the size shrinks slightly to 55K. By putting these classes and resources in a JAR file, you get an even greater reduction in program size.

The Uncompressed Size row contains the sum of the Class File Size and the Resource Size values. The JAR Size row is the size of the compressed JAR, which includes both the classes and resources. As you can see, removing the debug information and saving the program in a JAR file results in about a 38 percent reduction in the number of bytes downloaded to run this program.

JAR File Sizes

javac *.java

javac -g:none *.java

Class File Size

46K

40K

Resource Size

15K

15K

Uncompressed Size

61K

55K

JAR Size

42K

38K

*JAR File Sizes*
	`javac *.java`	`javac -g:none *.java`
Class File Size	46K	40K
Resource Size	15K	15K
Uncompressed Size	61K	55K
JAR Size	42K	38K

12.2.2 Download Time Reduction

The benefits of JAR files go beyond just reducing the number of bytes that have to be downloaded to run your program. A major problem for web-deployed applets has to do with inefficiencies in the HTTP protocol. Clients connected to HTTP servers can generally download large files fairly quickly. However, HTTP is a poor protocol for downloading a lot of small files. Each file request sent to the server incurs additional overhead. If you put your program on a web server as a raw collection of classes and resources, a client downloading the program has to make a separate request for each file. This can be very slow for the client and increase s the load on your web server.

To demonstrate the effectiveness of JAR files, the SwingSet demo applet was rebuilt and deployed two ways. First, all of the individual classes and resources were loaded into directories on a web server. Second, all the classes and resources were packed into single JAR file. Table 12-3 shows start-up times for several runs of the applet. For this test, a PC client was used to download the applet from a Solaris server running Apache web server on a 10base-T LAN. The times were measured with a stopwatch.

When the applet is deployed with a JAR file, the start-up time is more than six times faster. The improvement is even more pronounced in the worst-case scenario. These results are representative of the improvements in download times that result from using JAR files. As always, however, the results can vary widely depending on the particular circumstances.

SwingSet Start-up Time

Run Number

Separate Files

JAR File

1

69.75 seconds

8.87 seconds

2

57.75 seconds

8.89 seconds

3

51.09 seconds

9.68 seconds

4

54.72 seconds

9.21 seconds

5

89.16 seconds

9.50 seconds

6

51.50 seconds

9.78 seconds

7

56.35 seconds

9.28 seconds

Average

61.47 seconds

9.32 seconds

Best

51.09 seconds

8.87 seconds

Worst

89.16 seconds

9.78 seconds

*SwingSet Start-up Time*
Run Number	Separate Files	JAR File
1	69.75 seconds	8.87 seconds
2	57.75 seconds	8.89 seconds
3	51.09 seconds	9.68 seconds
4	54.72 seconds	9.21 seconds
5	89.16 seconds	9.50 seconds
6	51.50 seconds	9.78 seconds
7	56.35 seconds	9.28 seconds
Average	61.47 seconds	9.32 seconds
Best	51.09 seconds	8.87 seconds
Worst	89.16 seconds	9.78 seconds

12.2.3 JAR Files and Resources

Converting an applet or application to run inside a JAR file is generally trivial- most of the time, no code changes are required. One case, however, is a common source of confusion: accessing files in the JAR file. When a file is not in a JAR file it can be accessed like this:

InputStream in = new FileInputStream("MyFile.txt");

However, if MyFile.txt is contained in a JAR file along with the class trying to access it, this code doesn't work. There is no longer a stand-alone file with the specified name; it's simply an entry in the larger compressed file.

To get around this problem, you need to use the Class.getResource and Class.getResourceAsStream methods. For example, to access the contents of MyFile.txt, you could use the following code:

InputStream in = this.getClass().getResourceAsStream("MyFile.txt");

See the documentation for Class for more information about the getResource methods.

12.3 Packaging Utilities

There are several commercial tools available that specialize in application and applet packaging. These tools typically provide you with the benefits of standard JAR files, but also claim several additional benefits. These generally include some or all of the following:

Removal of unused code
Code compression/obfuscation
Reduced RAM footprint
Faster runtime performance

Generally, these tools work by analyzing your class files and stripping dead code in a fashion similar to a traditional linker tool. They also modify the class files and shorten the names of fields and methods. For example, a method called getCustomerAddress might be shortened to simply a. This reduces the size of the class files and the JVM constants pool at runtime. There are many reports of developers getting 30 to 70 percent reductions in program size by using these packaging tools. Using a packaging tool can also reduce RAM footprint, though the reductions are usually fairly small.

Before deciding whether to use a packaging tool, be aware that some of these techniques are difficult for an automated tool to perform in a system that supports reflection and dynamic class loading, as the Java language does. For example, if the tool changes the name of a method that you try to look up with reflection, your lookup will fail. Some of the commercial tools have mechanisms to help you deal with this, but they often require manual intervention.

Another consideration is that the obfuscation of your code can make field debugging more difficult. For example, stack traces are often very useful in isolating bugs. After compression/obfuscation by one of these tools, however, the stack trace might no longer contain the original method names.

The claims that some tools make about improving program execution speed typically apply to code running in an interpreted environment. The techniques applied by these tools are much less compelling in an environment with a JIT-all of the speed optimizations available to static packaging tools are also available to JIT systems. Today's code generators currently implement many of these optimizations, and more and more of these optimizations will be implemented in the future. Obfuscators can actually make it harder for JITs to figure out how to generate optimal code, so it's important to consider your target environment when deciding whether or not to use a packaging tool.

Overall, packaging tools are useful in certain situations, particularly if you are very concerned about application size. You should evaluate these tools with your own code and develop benchmarks for the performance aspects that are important to you. When evaluating the results, keep the concerns related to reflection and dynamic class loading in mind-even if you aren't using these features right now, you might want to in the future. Before making any final decisions, discuss these issues and any other concerns you have with the product vendor.

12.4 Dynamic Downloading

A disadvantage of the JAR file format is that you have to download the entire JAR file before any of the classes it contains can be loaded. Even if only ten classes have to be downloaded before your applet's initial screen can be displayed, the client still has to wait for the entire applet to download before the program can start. As discussed earlier, the HTTP protocol is poor for downloading a lot of small class files, so just putting all of the individual files on the web server instead of in a JAR file doesn't really help. To address this problem, commercial products have recently been developed to support more dynamic downloading.

These dynamic downloading products generally require that you run a separate custom server process on the same machine as your web server. When a client requests your applet, a specially constructed small applet class is downloaded instead. This applet class, called a stub, then downloads the rest of your classes by making a connection (using a custom protocol) to the custom server process. This process is illustrated in Figure 12-1. Since the class file server doesn't have to use the HTTP protocol, it can download the classes much more efficiently. This type of system can also download classes in the background while the user performs other tasks.

While systems like this are new, they do show promise. The main drawback is that they require an additional process to be run on the web server, which is not practical in all environments. If the custom process can be run in your deployment environment, however, you might want to consider this option to maximize start-up performance.

Dynamic class loader configuration

12.4.1 Applet Caching

Newer versions of Sun's Java Plug-in (starting with version 1.3) cache downloaded applet JAR files. The first time an applet is run, it is downloaded normally. On subsequent runs, however, the applet loads with the same speed as if it were installed locally. This is an excellent option for applets that will be used by clients on a regular basis.


Key Points Although deployment choices might not affect your code, they can have a big impact on perceived performance. You can control whether debugging information is included in your class files. Removing debugging information can make your class files smaller. JAR files provide compression and are more efficient to download from web servers. Commercial packaging tools can be useful, but there can be issues with dynamic class loading, reflection, and debugging. Carefully evaluate any product before putting it into production use.

[Contents] [Prev] [Next] [Index]