like draw them on-screen. The decision to base the AWT architecture around peers had some important consequences, and development efforts must usually take these into account:

Benefits

There is less code to write in the API, since the underlying platform does most of the work.

GUIs look and behave as they would on the operating system on which they are run.

Drawbacks

If you want to support true platform independence, you must consider the least common denominator when providing components. This means that AWT GUIs are not as feature-rich as they could have been with other approaches.

If there are any quirks in the graphical components of an operating system, the AWT application inherits those along with the functionality.

Since peers have to be used for many operations of the GUI components, they can potentially slow down an application and present scaling issues.

Because of the drawbacks of the peer components, it might be better for developers to directly extend one of the two base classes of the model: Component or Container. Since neither of these classes has native platform peers, any direct subclass of them would inherit the core functionality of AWT without suffering from the limitations of the peer architecture. Naturally, this comes at a price—developers have to write the code to draw components from scratch.

The Swing Architectural Model

The entire Swing architecture is based on the concept of extending functionality from the AWT Container class. This includes the vast majority of graphical components in Swing subclass JComponent, which is itself a subclass of the Container class in AWT. This basic architectural decision has a number of consequences:

Swing is built on the core classes of AWT, so it inherits the basic AWT model. This means that Swing applications use the same approach for arranging space (the layout managers, containers, and components) and handling events. It also means that developers can use similar coding techniques for both Swing and AWT applications.

Since most Swing components are mostly Java code, there's a lot more flexibility. It's possible to create a much larger set of graphical components and make them much more customizable since they're basically smart pixels on-screen.

Swing components are subclassed from Container, so they can all hold other components. This is a big change from the AWT model, where only a few selected graphical elements were able to hold other items.

Building an entire architecture on another one is not without drawbacks of course. The inheritance hierarchy for the Swing classes can get fairly complex, and can sometimes make it difficult to see exactly where behavior is being performed. The JButton class is a typical example; its inheritance hierarchy is shown as follows:

Object > Component > Container > JComponent > AbstractButton >

JButton

There are still a few heavyweight classes that remain in Swing. They must be heavyweight in order to interact with the underlying operating system. The four top-level windowing classes are heavyweights, subclassed from their counterparts in AWT, and are shown in Table 6-1:

189