Digital Edition

The Argument for Custom Component UIs
The Argument for Custom Component UIs

The idea of the AWT (the Abstract Window Toolkit) is to make a platform-independent way to build UIs. That is a noble and worthwhile goal, to be sure. Unfortunately the AWT falls into the same traps that so many of the other tools targeting platform independence did years ago. Walking the tightrope between usefulness and platform independence, the AWT often fails to achieve one for the sake of the other.

A prime example is AWT heavyweight components, especially with respect to text rendering. All windowing platforms have a similar concept of text rendering and fonts. If you've developed in MS Windows, any of the Mac OS's, Unix X-Window or any other platform targeted by the AWT, you'll recognize a similar functionality presented by the AWT's Font class (and its relationship to the Graphics class).

Let's start by concentrating on the Java 1.0 AWT (later we'll see how Java 1.1 is a little better at doing text rendering and Component presentation). In 1.0, every UI Component object has its own default Font that is to be used when rendering text on that Component. The Component class, which is a base class for all UI Component classes in the AWT (both functional heavyweights such as Choice, List and Button as well as customizable heavyweights such as Canvas, Panel and Frame), has two methods to support this: getFont() and setFont(). In addition, each Component object has a package-private member named (appropriately enough) "font". The Component class implementation of getFont() looks something like this:

public Font getFont() {
if(null != font)
return font;
if(null != parent)
return parent. getFont();
return null;

This means that if a UI component doesn't have a display font that has been set explicitly (using the Component's setFont() method), then the component uses its parent container's default font for rendering text automatically. This is nice because it means if you want to set a default font to be used by all components within a UI, just set the default font of the top-most Frame window in your UI. All other components that are children of that Frame will use the parent Frame's default font.

And for those of you who don't know how it's done, this is how a component's default font actually gets used. In order to render itself to the screen, each Component object's paint() method is called at appropriate times. The paint() method is handed, as an argument, a Graphics object. By the time paint() is called, the Graphics object's text rendering font has been set to the component's default font.

How This Is Done
It turns out that a component object's paint() method is almost never called directly. Instead, each component's update() method is called. The update() method is declared in the Component class definition, and given an implementation like this:

public void update(Graphics g) {
g.fillRect(0, 0, width, height);



As long as the call to a Component's paint() method is invoked by that object's update() method, then the component's default Font is automatically selected into and used by the Graphics object. That's the idea, anyway.

This is why if you implement a component to just paint a piece of text (by extending the Canvas, Panel, Dialog or Frame classes with your own class and implementing the paint() method), it's the component's default font that will be used to draw the text.

Problems start when you try to use the so-called heavyweight component classes included with the AWT. These include the Button, List, Checkbox, Choice and Label Component classes. The design of these classes, and the definition of the 1.0 AWT, is such that use of default fonts in these types of components actually may not work. For example, if I wanted to make a Button in my UI and have that Button display its command label using a 30 point, bold Helvetica font, most 1.0 AWTs wouldn't use my font of choice. Instead of using the font I gave to the Button object's setFont() method, the Button would just display on the screen using an AWT-wide default display font. The font I specified to the Button's setFont() method would be completely ignored.

I don't know for sure why most AWT heavyweight components act this way, but it seems to be a pervasive problem for most 1.0 AWT implementations. I've witnessed the problem using many different 1.0 MS Windows and Mac VMs. It seems that a Button, or a List, or a Choice object really was meant only to be displayed exactly one way in these AWT implementations. That one display presentation uses the exact same display font, background color and foreground color for all heavyweight components in the AWT. Note that these are reportedly some VMs that have better AWT implementations. That is, VMs that in fact use the component's own default font, background color and foreground color for display of heavyweight components. I think, however, that these VMs are by far in the minority.

I've noticed that the JDK's 1.1 AWT implementation no longer has this "system-wide display font" problem with heavyweights. Instead, you can set the display fonts, background colors and foreground colors individually for all components and they actually are reflected in the display. (Note that this article was completed before I had a chance to experiment with the MS Internet Explorer 4.0 VM, which is a near-1.1 VM and new AWT implementation, so that too may no longer have this problem).

After probably taking too much time explaining the problem I wanted to talk about, I'm now going to describe the solution: only use heavyweight components in the rarest of circumstances. Due to the fact that the List, Label, Choice, Button and Checkbox classes were designed to give you a lowest-common-denominator functionality across all windowed operating systems, they end up being all but useless. Only in rare situations do you really have need for such simplistic, visually ugly UI components.

There's another problem with these types of components: they actually end up looking radically different when displayed with different AWTs. A Button object displayed using an MS Window's AWT is going to look very different than one using an X-Window's AWT. The one in Windows will look like a Windows button, and the one in X-Windows will look like an X button widget.

Some developers I've talked to see system-dependent display as a good thing. They like the fact that components will display more like what the user expects and is used to. The user will know on a Mac machine what a Mac button does. I agree that this may be a nice feature of heavyweight components such as Buttons. However, the Mac windowing system also has several UI component types with absolutely no equivalent in the AWT; Hierarchical tree components, tool palettes, etc. There are no AWT equivalents for these MAC UI components. So, to achieve similar functionality within a Java UI, you must create (or purchase from a third party) custom components. And these components, though achieving the same functionality as the Mac UI components, will almost certainly not look the same as the Mac equivalents.

Listing 1 is code for a ClickableLabel custom component, written entirely within Java. A ClickableLabel has the same capabilities as a heavyweight Label component, with the added ability to receive and handle mouse clicks. Note that I had to re-implement Label functionality within my Canvas-derived class. This is an unfortunate fact about heavyweights, you just can't count on being able to derive new classes from them to add your own functionality. Most AWT implementations do not behave as expected when you derive > from a heavyweight class.

So, for a UI with all but the most trivial, dialog-like interface, you're going to have to show the user UI components that are maybe not exactly what the user has seen before. That is, using custom components that are not necessarily targeted towards the underlying target platform. This is a given. There's almost no way around this problem. So, why not just build the entire UI out of custom components?

Evidence supporting the strategy of building entirely pure Java custom components based on the Canvas, Panel, Dialog or Frame classes exists in two new component packages: Sun's JFC (Java Foundation Classes) and Microsoft's AFC (Application Foundation Classes). These are two new sets of entirely pure- Java UI elements. The idea is that, when building UIs in Java, use of pure-Java components will make your interfaces guaranteed not to be platform-dependent. They will look the same, no matter what underlying windowing system is used to display them.

That last statement is not exactly true. Sun's JFC UI components have a set of requirements which include having a pluggable "look and feel". This means you can tell a given JFC UI component to act Mac-ish, or MS Windows-ish or to target a look and feel like any particular underlying windowing platform. With the JFC classes you end up having the option of visually presenting the user with a look and feel he is comfortable with. Unfortunately, the set of "looks and feels" could never encompass all potential target platforms, for each individual UI component. Maybe that's a goal of the JFCs, but I just don't see it happening because of all the work that it would entail. For popular platforms (Mac, MS Windows, X-Motif), you'll have looks and feels available. For most other platforms (WebTV-type boxes, gaming systems, etc.) you're going to have to "roll your own" pluggable "look and feel", most likely.

Note that Sun's JFC components are designed to work with 1.1 VMs and AWT implementations. This is the one drawback I see to using the JFC classes. The AFC classes will work on any 1.0 Java platform. On the other hand, the JFC classes are destined to become part of the standard core Java platform, meaning they will be available eventually in every browser and standalone VM. The AFCs, being Microsoft's preferred UI toolkit, may become available on all Microsoft VMs, but the chances are slim that they will become part of a standard Java platform.

In addition to the JFC and AFC class packages, several different third-party vendors have built UI component packages you can purchase and distribute. Again, these third-party packages are designed around the pure-Java component idea. No matter which underlying platform these third-party UI components are deployed on, they will always work the same and display the same. The difference between third-party packages and the JFC classes or AFC classes is that third-party packages will have to be purchased. Both the JFC and AFC packages are free. On the other hand, many third-party packages have some pretty nice visual components such as pie charts, bar graphs, etc. Buying such component packages generally will end up being a lot cheaper than rolling your own.

In any event, I've tried to lay out an argument for basically ignoring the heavyweight classes distributed with the 1.0 Java AWT. These classes are the List, Button, Choice, Checkbox and Scrollbar classes. Instead, to ensure platform-independence, you should stick to using truly pure-Java UI components. Those components may be Canvas, Panel, Frame or Dialog-derived classes. You can build your own (an example is given in Listing 1), use Sun's JFC or Microsoft's AFC UI component packages, or purchase third-party packages. I can guarantee you'll be happier with the results.

About Brian Maso
Brian Maso is President of Blumenfeld & Maso, Inc., a Java and Media consulting company. In addition to his involvement in several commercial Java projects, he is also the author of several Java books, including Osborne/McGraw-Hill's upcoming title "Visual J++ From the Ground Up". Brian is the Java guru of DevelopMentor's Java training courses. He has also written several Java white-papers for individual

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Subscribe to the World's Most Powerful Newsletters


Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple ...
Everyone wants the rainbow - reduced IT costs, scalability, continuity, flexibility, manageability, ...
SYS-CON Events announced today that Silicon India has been named “Media Sponsor” of SYS-CON's 21st I...
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use ...
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT...
SYS-CON Events announced today that has been named “Media Sponsor” of SYS-CON's 22n...
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 20...
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with e...
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point wh...
DXWorldEXPO LLC announced today that ICOHOLDER named "Media Sponsor" of Miami Blockchain Event by Fi...
Today, we have more data to manage than ever. We also have better algorithms that help us access our...
DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, ...
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held Novemb...
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: D...
CI/CD is conceptually straightforward, yet often technically intricate to implement since it require...
The now mainstream platform changes stemming from the first Internet boom brought many changes but d...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (No...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018,...
SYS-CON Events announced today that IoT Global Network has been named “Media Sponsor” of SYS-CON's @...