Previous column

Next column

Resource Bundling for Distributed Computing

Douglas Lyon, Fairfield University, Fairfield CT, U.S.A.

space COLUMN

PDF Icon
PDF Version

Wantonly hacked by an endless stream of nameless,
faceless undergraduates,
both men and women,
often by more than one at the same time,
Kahindu fell into a hell-hole of depravity.

– DL, 1998


This paper describes techniques for integrating programs and their resources. The goal is to distribute the programs, to a variety of platforms, without loosing the resources that they need in order to run. Programs so integrated are less fragile than their non-integrated counterparts. The techniques described include the use of a semi-automatic source code synthesizer, XML-based serialization and a base-64 GZIP encoded string format.

The approach is suitable for small data objects (i.e., icons, short audio signals, etc.). It has been used, with good success, on a variety of projects. One drawback of the technique is that an added step is required during program development in order to integrate resources into the code. Another drawback is that integrating resources into the source code can dramatically increase the size of the class files. On the other hand, once the class files are loaded, the resources are available in memory (and hence, quickly accessible).

The techniques described are a part of the Kahindu project, a joint project between the skunk works of DocJava, Inc. and Fairfield University. Kahindu is the name of a village in Kenya known for its fine coffee.


One of the basic problems with Java programs is the fragility that results when data is decoupled from source code. For example, suppose that you write a program that seeks to make use of an icon in an interface. In order to load the icon, you write:

LookAndFeel.makeIcon(getClass(), "icons/ColorIcon.gif"));

Now suppose the GIF “ColorIcon” icon file is relocated, relative to the root of the source code. This can easily happen during the process of distribution or development. Even worse, the missing resource is not detected until run-time (perhaps days or even weeks after deployment). For example, if you try to deploy an application that attempts to obtain the above icon, without having it properly integrated into the application, you would throw an exception, like:

Wouldn’t it be nice if the compiler could make sure that our resources were present, before run-time? In this way, we trade off a run-time error for a compile-time error. We present some techniques that allow resources to be integrated directly into source code. The result is a self-contained resource without the normal source of fragility (i.e., source relocation). Hence, we no longer have a program that requires files to be located in particular places on the disk.

The presented technique can be used for any type of resource. Initially, we focus on icons. We present the ability to create icons in one of three ways: by grabbing the icon using a screen grabbing program, by drawing the icon using either the Kahindu drawing tools or another paint program and finally, by entering the icon using teletype graphics. Finally we present an encoding technique that automatically generates Java source code from serializable instances.

Icon Design by Grabbing

There are often icons that are available as a system resource that can be freely copied. These icons start as bit-maps and may be scaled in size to suite the application. The Kahindu program will accept icons of any size. Several applications are able to take snapshots of the computer screen. These applications vary from platform to platform. For example, Silicon Graphics workstations have an application called Snap, which will save a snapshot of the screen. On the Mac there is a keyboard shortcut, <shift-Moth-4> (or the grab application) which changes the cursor into a cross hair and allows the user to click and drag across the screen.

Depending on the platform, the screen shot will be saved to a file or to a clipboard. The clipboard enables the screen shot to be pasted into another application. Unfortunately, Kahindu is rather limited in the number of file types that it currently supports. Thus, a third-party application is required to convert the snapshot into an image that Kahindu supports. Currently, this means GIF, PPM or JPEG files. Suppose, for example, we wanted to grab the icon image from the system to symbolize magnification. Fig. 1-1 shows an image of the magnifier icon. This was grabbed using the screen capture facilities on a Mac.

Fig. 1-1. The Magnifier Icon

Using an application called Debabelizer [Debabelizer], we save the icon image to a GIF file and open it with the Kahindu program.

Fig. 1-2. Save As Binary Icon

Fig. 1-2 shows that the Kahindu program has a menu for saving the binary icon image.

Fig. 1-3. Binary Icon Output as Java

Fig. 1-3 shows the binary icon output at the console as a two-dimensional static byte array. Such data takes very little space in the program (15x15 = 225 bytes) and its’ space is allocated at compile time.

Icon Design by Drawing

Another method for obtaining a binary icon is to draw it. Several excellent paint programs are available that can help with drawing icons (including Kahindu).

Fig. 1-4. The Kahindu Toolbar

Fig. 1-4 shows an image of the Kahindu toolbar. From left to right, the icons are identified as the eraser, pencil, paintbrush, hand, magnifier, marquee, paint can, eyedropper, and marker. To draw or modify an existing icon, use the eraser, pencil, brush, magnifier and eyedropper. The eraser will clear pixels in the icon. The pencil will set pixels to the value selected with the eyedropper. The brush will set a larger array of pixels than the pencil. Normally, the icons are small. The Kahindu toolbar icons are all 15x15 pixels in size. As a result, the magnifier is used to make the image easier to work on.

Fig. 1-5. Using the Magnifier to Expand the Paint Brush

Fig. 1-5 shows an example of the use of the magnifier icon to enlarge the paintbrush image. This type of enlargement works by doubling the number of pixels in the icon, and thus growing the icon. To keep the icon the same size, but to enlarge it on the screen, simply resize the frame. Once the frame is enlarged, use the drawing tools to modify the icon.

Fig. 1-6. Elements of One Icon Can Be Used to Create Another

Fig. 1-6 shows how the bristles of the brush were reused to make a face. The design of icons is an art and it takes great care to find icons that have cross-cultural meaning. For example, icons should probably not contain English language characters, as these are not well known in all cultures.

Icon Design by Typing

The programmer can design icons by hand-keying them into the byte array. The IconFrame class resides in the Kahindu gui package. It contains several icons, some of which were typed by hand. Sometimes this is the easiest way to enter an icon, as it gives fine-grained control over the value and location of each pixel.

Fig. 1-7. Hand Typing an Icon

Fig. 1-7 shows the marker icon, as it was hand-encoded into the IconFrame. The shift by exactly one pixel during each entry of the zeros in the array, as well as the precise centering of the mark, is simplified by hand entry. In fact, some programs (such as Maple) can output Teletype graphics, like that shown in Fig. 1-7. The Internet is a good source of Teletype graphics, as they are still e-mailed occasionally.

Saving the Icon as Java

Now that you have obtained the Java source code needed for an image, you must assign it a name. This is done in the IconFrame when the static array is formulated in the Java code. For example:

Once the byte array is formulated, an IconComponent is created, using the getIconComponent method:

The IconComponentinstances are added, using:

Once the icons are added to the iconPanel instance, they will be available upon program start-up (i.e., without the need to access the file system). For use in Swing, programmers can get an instance of a javax.swing. Icon by using:

Icon icon = Icons.getMagnifierIcon();

Event processing occurs both in the IconFrame instance and in the frames that are associated with the icon’s state. For example, in the PaintFrame, there is a method called mouseDragged which checks the iconFrame instance for the selected icon:

The IconComponent instances act just like other components in the AWT, except that they know how to invert their own appearance. They can be added to panels and layout managers can arrange them, just like other components. The IconComponent instance keeps a private copy of an image of its own appearance.


This section shows how an instance of a serializable class can be transformed into a static variable. The static variable is used to reconstruct the instance, at run-time, thereby integrating the resource directly into the source code. Consider the Address class, a fragment of which follows:

An instance of the Address converts itself to XML using the java.beans.XMLEncoder:

The XMLEncoder shows:

A static method in a utility class converts the above code into a static string that can be embedded into a Java program:

This can be decoded using:

Thus, we can test the XMLDecoder using:

It is possible to serialize full-color images using XML, but this is really inelegant. For example, an instance of the ShortImageBean:


This uses 6 lines for every pixel! Such expansions are too cumbersome even to contemplate. The following section addresses this concern by using a base-64 GZIP encoding technique.


This section shows how to GZIP compress, and base-64 encode, an instance of an object, so that it is suitable for storage into a Java string. This is far more efficient (in terms of memory and CPU time) than creating XML strings. The technique suffers from the fact that the output is not readable by humans and cannot be hand-edited.

The following example turns a full color image into a base-64 GZIP encoded string, then decoded and displayed for view.

The following code shows how the GZIP base-64 encoder can be used to synthesize a Java static variable declaration:

The following code example demonstrates how to decode the embedded object:

More generally, we write:

One drawback to this technique is that string constants can be too long, causing the java compiler to choke. For example:

Even editing such files can cause some IDEs (like IntelliJ) to bomb out. The question of how to address this problem (perhaps by breaking up the strings) remains open.

As a final example, we present a series of icons used in our new GUI for image processing. These icons are integrated into an Images class:

The output of the new interface, with the integrated icons, is shown in Fig. 2-1.

Fig. 2-1. The Application with Integrated Icons


In summary we look to avoid storing resources in external files in order to speed resource loading and improve reliability of our programs. This is a natural outcome of resource integration with source code.

The idea of storing icons in source code is not new [Lyon], but the idea of storing serialized XML encoded objects in Java source is (as far as I know).

There are definite limitations to the technique of storing objects inside of a Java program. For one, there is a reliance on classes implementing the serializable interface. For example, the Image class does not implement the serializable interface. On the other hand, writing ad-hoc techniques for storing images has the benefit of creating a nice structure for hand editing.

It is equally clear that large arrays of data could create a cumbersome burden during compilation. In fact, some compilers will not allow a static array that is larger than 64K bytes. It is generally recognized that this is not a limitation of the Java language specification, but rather of the implementation of the compiler.

Other failures to serialize into Java source can result from using inner classes. For example:

cannot work because Foo is an inner class.



[Debabelizer] Debabelizer is a useful program for batch image conversion and processing, available from: Equilibrium, 475 Gate Five Road, #225, Sausalito, CA 94965. Phone: (415)332-4343.

[Harder] Robert W. Harder, “Base64”, A Public Domain Java class providing very fast Base64 encoding and decoding in the form of convenience methods and input/output streams. See

[Lyon] Douglas A. Lyon, Image Processing in Java, Prentice Hall, Upper Saddle River, NJ, 07458. 1999. Available from



About the author

space After receiving his Ph.D. from Rensselaer Polytechnic Institute, Dr. Lyon worked at AT&T Bell Laboratories. He has also worked for the Jet Propulsion Laboratory at the California Institute of Technology. He is currently the Chairman of the Computer Engineering Department at Fairfield University, a senior member of the IEEE and President of DocJava, Inc., a consulting firm in Connecticut. E-mail Dr. Lyon at His website is

Cite this column as follows: Douglas Lyon: “Resource Bundling for Distributed Computing”, in Journal of Object Technology, vol. 4, no. 1, January-February 2005, pp. 45-58.

Previous column

Next column