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:
JavaWorld.com > Java Enterprise Edition >

Java performance programming, Part 3: Managing collections

See how collections alternatives measure up in performance, and find out how to get the most out of each type

By Dennis M. Sosnoski, JavaWorld.com, 02/01/00

In Java performance programming, Part 2, we looked into the basics of casting -- what it is, what it costs, and some ways you can reduce your use of it. This month, we'll cover the related issue of collections in Java, looking first at the basic collections support supplied in the original versions of Java, then moving on to the vastly improved support added in JDK 1.2. Looking ahead, we'll also examine the current state of the Java Community Process proposal for generic types in Java -- including both the benefits we're likely to see from this proposal and the areas in which it perhaps falls short.

TEXTBOX:

TEXTBOX_HEAD: Java performance programming: Read the whole series!

:END_TEXTBOX

We'll then take a look at ways to implement type-specific collections in Java, including an approach that uses a common base class to eliminate some of the duplicated code for these collections. Finally, we'll finish off this month's performance tips with the results of timing tests to see how our alternatives measure up.

(Note: See the sidebar below for my views on the effectiveness of Sun's Java Community Process.)

Vintage collections: Vector and Hashtable

If you're developing for JDK 1.1.x, your standard collections support includes just two choices: java.util.Vector and java.util.Hashtable. (There is also java.util.Stack, but this is only a minor variation on Vector). To make matters even worse, the two choices you do have available are noticeably handicapped in the performance area. Both classes use generic java.lang.Object references, creating the need for casting -- with the overhead associated with it -- on virtually every access, and both use synchronized methods for all accesses.

You need synchronized access methods for modifiable collections when they're used by multiple threads. However, in many cases a single thread owns and exclusively accesses a collection. In such a situation, synchronized access methods are overkill, and result in a substantial performance penalty.

We'll discuss the issue of synchronization further in the next article in this series, along with other threading issues. If you can't wait until then, the performance comparison table near the end of this article includes figures for the legacy Vector class that should give you a feeling for how heavy use of synchronization can affect performance.

Given the performance limitations, these old-time collection workhorses are generally best avoided in heavily used code. Just remember that they're still useful when you need only a simple collection and when performance is not a major issue.

There is a way to get improved standard collections support in JDK 1.1.x, but it comes with a price in terms of code compatibility. We'll discuss this further in the next section of this article, but for now let's limit our discussion to these two basic collections classes provided as part of the standard Java class library.

1 | 2 | 3 | 4 | 5 | 6 |  Next >
Resources