The world of Java depends on two established GUI toolkits: Swing and SWT (standard widget toolkit). Both software packages provide the widgets, controls, menus, and user interface components in most Java applications today. Swing, which Sun bundles with Java, first shipped with Java 1.2 in 1998. SWT, developed by IBM, must be downloaded separately. Its most famous application is the Eclipse development environment.

Both toolkits have their strengths and weaknesses; Swing is fast and comprehensive, but tedious to program for. SWT is easy to program for, but offers only a subset of Swing's functionality. One complaint that is equally valid for both is that they receive insufficient attention from their respective companies. It's clear that keeping the GUI functionality advancing is not a first-order priority for the developers at either Sun or IBM.

Thus, it was with considerable interest that I examined a third toolkit, Jambi from Trolltech. The company makes arguably the finest C++ GUI library today and is wholly focused on GUI development. I previously reviewed the C++ library, known as Qt, in 2005 and found every aspect of its implementation to be superior. Jambi shows a lot of promise, but it has some rough edges that were notably absent in its forebear.

Brewing Java

Jambi ships as a single Java library, or JAR (Java Archive) file, plus a handful of tools, including an interface layout and design tool, and an Eclipse plug-in. Trolltech uses its vaunted Qt C++ library as the GUI engine and puts Java wrappers around it. This approach uses the JNI (Java Native Interface) to call the necessary functions from Java. This design, which is also used by SWT, works well. It employees the native widgets whenever they exists, which guarantees an accurate look and feel for applications. For example, Qt Designer (pictured here) provides a rich palette for designing screens and dialog boxes interactively, and Qt Jambi (pictured below) delivers an array of rich visual capabilities. The problem with this approach is it can lead to lesser performance as actions are moved through the Java/native barrier. In actual practice, however, I did not notice any such slowdown.

The Jambi widgets tend to be smarter than their pure Java counterparts: The resizing behavior can be injected into a container rather than being specified for each and every widget on the screen. Defaults are more intelligent as well. For example, all text fields are scrollable by default. In essence, it's as if someone took Swing or SWT and redesigned them from scratch to be more intelligent and easier to use. The clean design, of course, is the product of Trolltech's years of developing GUI tools and having a company entirely focused on that one mission.

Because of this narrow focus, Jambi manages to deliver exceptional ease of development. It's simple to program, requiring only a short learning curve. After working with it for a few days, you come to anticipate the names of objects and methods you're likely to use -- a tribute to its consistent and clean API design.

This impressive ease of use greatly exceeds that of SWT, and in several key areas, it trumps Swing as well. Graphics functions support native graphics or OpenGL. Text can be true rich with multiple typefaces in different colors and sizes displayed simultaneously. The complement of widgets or controls is a superset of both Java toolkits, and it includes numerous complex and high-level items.

Jambi also delivers many functions that are not specifically related to graphics or user interfaces. One example is a wrapper class for network sockets. The high-level and low-level functions Jambi provides make simple work of writing to an HTTP server, which is included as a demo application. Additional areas of functionality include collections, internationalization, thread and process management, as well as property and resource management. That's a considerable amount of utility delivered in clean, intelligent library.

High marks for C++ developers

My most pressing complaint is that the package lacks a Java feel. You cannot escape knowing it is a ported C++ library. The Jambi documents frequently refer to C++ concepts and often link to C++ documentation, even when explaining a Java concept. This is fine for existing Qt users who see in Jambi a port to Java, but it is hardly what a Java developer would expect or even care to deal with.

In other areas, Jambi has some requirements that a Java developer needs to know up front. For example, threaded applications that use Jambi for the GUI must also use Jambi's low-level thread functions throughout. Using Java's own thread functions will lead to errors. In other cases, these unexpected items are directly beneficial -- such as Jambi's elegant way of solving some classpath difficulties, which are one of the known weak points of Java desktop applications. However, this shortcut requires Java developers to step out of the normal way of doing things and they will frequently feel caught off guard. Unfortunately, should difficulties arise in this regard, tech support is based in Europe and provides assistance only via e-mail. For U.S. developers, turn-around on support requests can be slower than desirable.

This first release is best suited to existing developers who use the C++ version of Qt. They will find Jambi to be a satisfying addition to their armory. For existing Java developers, it may be a tougher sell. Certainly, a library that has more functionality than Swing and is easier to use than SWT has potent appeal. However, it can be used only on green-field projects, as combining GUI toolkits is not advised. Using Jambi means abandoning both free toolkits -- and starting in on a new learning curve, short as it is.

Personally, I think Jambi is an excellent choice on a new project because of its extended capabilities, even though it is not free (unless you're working on an open source project, in which case a no-cost version is graciously made available). I'd still recommend waiting for a rev or two, so that the documentation and support for Jambi can be made truly Java-oriented.

Andrew Binstock has reviewed hardware and software for InfoWorld for almost a decade. During that time, he was also the editor in chief of Dr. Dobb's. Previously, he was a technology analyst at PricewaterhouseCoopers. He is a long-time software developer and contributes to open-source projects.