"Swinging" with Java Foundation Classes

This week we're going to start getting down and dirty with Foundation Classes. We're going to examine how they work and try to explain them--and what we find may not be pretty.

Let's start with the basics. The first thing not to like about foundation classes is the name. Calling something a "Foundation Class" is giving it a marketing name, which is considerably different from an ordinary functional name. Functional names are designed to tell you what something is about, and marketing names are designed to keep you from finding out.

Foundation classes, as far as we can see, don't relate in any way to foundation. They're a set of enhancements to the graphical user interface portion of Java--to the AWT.

The second thing we don't like about foundation classes is their separateness. Some time ago we talked about the enhancements to the AWT that are happening as the Java API evolves. Good management principles dictate that your updates be called updates, and be numbered and organized as consistently, as clearly, and as ostentatiously as possible.

Perhaps thinking they were somehow combating initiatives at Microsoft, the Java team elected to produce a certain round of AWT enhancements with a special spin--and that's the Java Foundation Classes.

But under all of the hype and bluster, what's really there? We were surprised to find that both the Microsoft attempt and the Javasoft answer show a degree of complexity of function and structure that we'd come to expect from other, nastier languages--but not from Java.

While the original intent of Java was focused and simple, and perhaps never even close to PC application development, the user interface tools were wonderfully simple. The AWT was rudimentary, but serviceable, barring the bugs that came from hasty implementation. For small, simple projects, it was absurdly quick and easy to use.

So it turned out there was some demand for Java to have some of the complex user interface features found in other operating environments. The Application Foundation Classes attempted to fill in the gaps with some extra tools and tricks, but at considerable expense. The JFC, trying to outdistance it, went one better. Swing represents a first attempt for the AWT to be as flexible, tool-rich, and complicated as some workstation-class application development systems, like Visual C++ and X/Motif.
 
Complexity like that is wonderful if you have a huge interface project on your "To Do" list and the world's best authoring tool on your desktop. If you don't, well, we're about to show you a little bit of why Swing probably isn't for you.

Let's start by looking at the "architecture" of swing components. The buzzword-compliant spec intends swing components to have an intricate, "pluggable" look and feel. The documentors call their system "venerable," but we urge you to judge for yourself. In it, interface components are composed of three elements:
 

• A model, which reflects "state" information about the component (i.e., for a lightswitch component, whether the lights are on or off)
• A view, which reflects the appearance of the component (i.e., the lightswitch color and size)
• A controller, which reflects how the component behaves in response to user input (i.e., linking up a click on the switch with a change of its state and appearance)

So far it sounds deceptively simple, but the goals here are very ambitious. The component itself is a complex class with get-and-set methods for managing a model, view and controller (which are actually bundled together in something called a componentUI object), universal component properties, and event listeners that want to attach to the component to see what it's doing.

There is an interface definition for ComponentUI objects. Then there are the actual classes that implement subclasses of that interface. There is an interface definition for Model objects and the classes that implement them.

To maintain consistency across many uses there are UIFactory objects, which provide mapping between interfaces and classes that implement them and to keep track of common properties for Swing components. The factories are configured from text files and need to be called with a "fallback UI" as an argument in case they are unable to resolve a request.

Does this sound complicated? It's getting there. The bottom line is that swing components, in order to accommodate the feature-craziness prevalent in some schools of modern application design, are now requiring more and more methods to be written to make them work, more thorough study to understand and control how they behave, and the intervention of a configuration system based on object factories.

No, it's not a real mess yet. We've programmed in X windows, and we know what a real mess is. But we can see it starting down that path, and it's disturbing.

Next week, more on the AFC and JFC internals. Stay tuned.