Into the "Swing" of Things

Last week we started our crash course in the Swing "architecture." This week, we're going to begin to talk about the set of tools that have grown out of its capabilities.

This is the part where we can start talking about some of the things we like about Swing. For all of this part of Java's rapid weight gain, it is still managing to pay dividends in functionality. First, for the benefit of those of you who've been following along, we should clarify a few things. Primarily, if we state that Swing--more properly, the AWT--is markedly more complex and difficult to grasp than its predecessor, we're talking about what's under the hood. So our continuing discussion of these objects will reflect on their growing internal complexity. If you're planning on writing Swing components, that means you're in for an experience.

If you're planning on just using them, then take some comfort. These are still just self-contained objects. In a sense, they're still the same GUI components you've come to know and love. Externally, their behaviors are generally the same. They're going to seem different to you only in as much as you use new features to exert new kinds of control over them. In theory.

Of course, functionality is often the first, best source of complexity.

Swing offers a number of components in the traditional sense. There are now classes for making cute window borders, tables, tree diagrams and progress bars, and many others we'll get into shortly. Many of these seem to be in fairly direct response to the earlier "Foundation Class" offerings. Some of them are, as we've already said, just what would have been an ordinary part of something called AWT version 1.2, with the same names that exist now. Instead, our industry is like a giant preschool playground. Microsoft and Sun are having a name-war, and Swing has its own Buttons, but they're called JButtons.

There are also JRad ioButtons, J TextAreas and JScrollbars, just like there are in the regular API. These elementary bits of user interface present in Swing represent its origins as just another version of the AWT. They're redone here so that they can benefit from the new Swing framework-- pluggable appearances & behaviors, better handling of keyboard shortcuts, inline graphics, and all the rest. The documentors have, in many places, indicated a desire to maintain source compatibility and simplicity of their current AWT counterparts, and in many instances have made excellent progress in this regard.

Then there's the framework itself. When we spoke some time ago about the future of the AWT, we foreshadowed some of the things that are now being proposed and standardized: Drag and Drop and a generic Undo interface are included. As many people in the Windows and Unix world know, it's impossible to conceive of successful implementations of Drag and Drop on a system unless the underlying mechanisms are standardized, so Java has begun to do so. And, while it may be hard for you seasoned programmers to guess right away how it could be possible to generically implement Undo, let us assure you there is something of substance there. We'll be back to look at that.

Finally, we should mention the last class of improvements in the Swing package, the utilities, or more accurately, the utility. In an interesting move, Sun has chosen to endow its JComponent class with debugging hooks, and has provided a utility for tracking and debugging the functioning of the components as they work. It's called Debug Graphics.

So, as you can see, we've got a lot to talk about. Hope to see you next week as we get right into it.