Developing GUIs

From its initial release, Java has included a number of classes for providing a graphical user interface (GUI). These classes were collectively known as the Abstract Window Toolkit
(AWT). In Java versions 1.0 and 1.1, the AWT was the only means available for developing GUIs.

Java Swing classes for developing GUIs became available with the Sun Software Development Kit (SDK) platform 2; this included version 1.2 of the Java language, so 1.2 or a higher version of Java should be used to develop Swing programs. Swing provides a larger set of components than AWT and has a much richer functionality than the AWT equivalents. Furthermore, an AWT GUI takes on a look and feel dependent on the underlying operating system, whereas with Swing it is easy to specify a look and feel for most operating systems. In this chapter, we describe Swing. Swing, however, is a very large topic. There are many components with associated classes, methods, and interfaces. In this section cover only the basics.

Three basic concepts behind Swing are containers, components, and event handling. A container can be regarded as a screen or part of a screen. A container has an associated layout, which determines how components are arranged when they are added to a container. Atomic graphical user components, such as buttons, radio buttons, lists, and check boxes, are placed in containers. These can be top-level containers such as applets or frames, or can
be placed in intermediate-level components such as panels, which in turn, are placed in the top-level containers. Event handling is the means by which user interactions are captured
by a program, for example, a user makes a selection from a list of available items.

Swing has separate model and view classes for components. The data is held in a model class and is displayed in a view class. For example, the button data model interface is ButtonModel, and the supplied class that implements this interface is DefaultButtonModel. The button view class is JButton. For most components, the model is kept in the background, and the application program interacts with the view class through supplied methods. However, for more complex components, such as lists and tables, we need to explicitly interact with the model classes. One consequence of this separation of model and view classes is that it is possible for certain components to share models.With the AWT, each component Java class had a corresponding device-dependent interface or peer that maps the classes execution code onto the underlying windowing system. So an AWT button includes Windows and Motif peer interfaces, for example. For this reason, AWT components are called heavyweight. Swing, on the other hand, is peerless, or lightweight, in that all component code is written entirely in Java. There are no device- dependent component peers; all the interaction with the underlying windowing system takes place within the top-level applet or frame containers. A consequence of this is that, whereas with AWT the GUI takes on a look and feel dependent on the underlying operating system, with Swing GUIs take on a Java look and feel by default although it is possible to specify a look and feel for most operating systems.

Although Swing supersedes the AWT, Swing still makes use of AWT classes especially in the area of event handling. Consequently, the Swing examples in this chapter will typically use java.awt as well as javax.Swing classes.