Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters

Email Address:

How Java uses the producer/consumer model to handle images -- An insider's look

Learn more about Java's powerful image-handling technique, then follow these simple procedures for building your own producer and consumer components

Not content with the complete set of graphics primitives provided by the Graphics, many programmers still find that they need more flexibility; simply loading and displaying images within an applet or application often doesn't make the grade. In these cases, the only solution is to create images on the fly. Such a task is made possible by Java's powerful image-handling framework and the two interfaces that make it up.

Before we get too deep into our latest image endeavor, let's review what we learned about images in the preceeding How-To Java column.

A crash course in image handling

Recall that delay is an inherent property of the network-based environment in which Java applets and many Java applications live. Because Java applets and many Java applications depend heavily on resources (classes and media) that are initially available only remotely, the designers of the Java class library had to address the delay posed by network transactions. The result of their efforts was a system in which images are fetched asynchronously, possibly in another thread.

The most visible player in the image game is the Image class. An instance of the Image class represents an image, but it does not need to contain the data that makes up the image -- the Image class provides methods for obtaining information about the image represented by an instance of the class. Due to network delay, information about an image might not be immediately available. Therefore, each method requires, as a parameter, an instance of a class that implements the ImageObserver interface.

Whew! That's a whole lot of information crammed into a very small space. If you find that you're scratching your head wondering what this is all about, check out last month's column, for more information.

Uncovering the power of the the producer/consumer model

The developers of the Java class library used the producer/consumer model as the basis for the library's low-level image-handling API. This model, which has several advantages we'll examine in a minute, consists of two tightly coupled components: producers and consumers. You may have been able to guess the components' names, but understanding what they do requires some explanation. Let's take a look.

Image producers are objects that produce image data. An image producer may generate image data itself, or it may provide access to image data in a particular image format (GIF, JPEG). All image producers implement the ImageProducer interface. Image consumers, on the other hand, are objects that consume image data. Once the image data is consumed, the object is then free to use (or modify) it. All image consumers implement the ImageConsumer interface.

As I mentioned a moment ago, the producer/consumer model has several advantages: it's modular, which means that existing producers and consumers can be used interchangeably, and new producers and consumers fit seamlessly into the existing framework; and it lends itself to asynchronous interaction, which means that once a connection between a producer and a consumer is made, the producer notifies the consumer only when more information is available. Meanwhile, the applet or application is free to do other work.

1 | 2 | 3 | 4 |  Next >
Resources
  • Previous How-To Java articles