Many data sources contain redundant data or data that is useless for storing information. This often results in a myriad of data transfers between client and server applications or computers. Clearly, the solution to the problem of data storage and information transfer is to install secondary storage devices and extend existing communication devices. To do this, however, requires an increase in the operating costs of the organization. One way to mitigate some of the data storage and information transfer is to represent data in more efficient code. This article briefly describes data compression and decompression, and how to efficiently and easily use Java.util.zip package compression and decompression data from within JavaTM applications.
Although tools such as WINZIP, Gzip, and Java ARchive (or jars) can be used to compress and decompress data, these tools are still used as stand-alone applications. These tools can be invoked from Java applications, but they are not a straightforward and efficient solution. This is particularly the case when you want to compress and decompress data quickly, such as before you transfer to a remote machine. This article will:
A brief review of data compression
Describe Java.util.zip package
Describes how to use these packages to compress and decompress data
Describes how to compress and decompress serialized objects to conserve disk space
Describes how to quickly compress and decompress data to improve the performance of client/server applications
Overview data compression
The most singular type of file redundancy is the repetition of characters. For example, the following string:
Bbbbhhddxxxxkkkkwwzzzz
You can encode this string more succinctly by replacing each repeating string with a repeating character and a number that represents its repeated count. Therefore, the above string can be encoded as:
4b2h2d4x4k2w4z
The "4 B" here represents 4 B, while the 2H represents 2 h, and so on. The encoding for compressing strings in this way is called the Run length encoding.
Another example is the rectangular image store. Because it is a monochrome bitmap image, it is stored as shown in Figure 1.
Figure 1: Bitmap with Run length encoded information