Category list

Chapter 13. Graphical User Interfaces

[Page 603]

Chapter 13. Graphical User Interfaces

OBJECTIVES

After studying this chapter, you will

Gain more experience with the Swing component set.
Understand the relationship between the AWT and Swing.
Learn more about Java's event model.
Be able to design and build useful Graphical User Interfaces (GUIs).
Appreciate how object-oriented design principles were used to extend Java's GUI capabilities.

OUTLINE

13.1	Introduction
13.2	Java GUIs: From AWT to Swing
13.3	The Swing Component Set
13.4	Object-Oriented Design: Model-View-Controller Architecture
13.5	The Java Event Model
13.6	CASE STUDY: Designing a Basic GUI
13.7	Containers and Layout Managers
13.8	Checkboxes, Radio Buttons, and Borders
13.9	Menus and Scroll Panes
	Are Computers Intelligent?
	Chapter Summary
	Solutions to Self-Study Exercises
	Exercises

[Page 604]

13.1. Introduction

As we have seen, a Graphical User Interface (GUI) creates a certain way of interacting with a program. It is what gives a program its look and feel . In preceding chapters, we have already used the basic components from which GUIs are created, including buttons, text fields, labels, and text areas. Throughout this chapter, we will focus on designing and building GUIs that are easy for users to navigate. However, Java's GUI libraries are so large that we will concentrate on only a handful of additional components , including containers, check boxes, radio buttons , and menus .

We will try to identify design principles that can be applied to the design of more advanced interfaces. Also, because Java's GUI classes provide an excellent example of object-oriented design, we will highlight some of the important design decisions and principles that have influenced the development of Java's GUI classes in both the AWT and Swing. Let's begin with a brief history Java's GUI libraries.

[Page 604 ( continued )]

13.2. Java GUIs: From AWT to Swing

Ever since the release of version 1.2 of the Java Development Kit (JDK) in 2000, Java has contained two distinct libraries of GUI components . The Abstract Windowing Toolkit (AWT) has been part of Java since the original 1.0 version of the JDK 1.0. The more advanced Swing component set was first introduced in JDK 1.1 and was extensively revised in JDK 1.2.

Although the original version of the AWT was suitable for developing Java applets, it wasn't powerful enough to support full-fledged applications. Commonly used programs, such as word processors and spreadsheets, have GUI requirements that were just too much for the original AWT. The main problem was that the AWT was dependent on the underlying operating system. This meant that Java GUI programs were forced to rely on GUI elements that were part of the underlying operating system. A Java GUI program running on a Windows platform had to depend on Windows code for implementations of its buttons and text fields. A Java program running on Unix depended upon underlying Unix code for its GUI components. Such dependence on the underlying operating system made the AWT less portable and less efficient.

In contrast, the Swing GUI components are part of the Java Foundation Classes (JFC), a collection of classes that do not depend as much on the underlying platform. The Swing library makes it possible to write GUI programs entirely in Java. Because they are rendered entirely by Java code, Swing components make it possible to design GUIs that are truly platform independent. Such programs are much more portable than those that rely on AWT components and the underlying platform. A program that uses Swing components will have the same look and feel on a Mac, Windows, or Unix platform.

13.2.1. Heavyweight Versus Lightweight Components

AWT components are based on the peer model , a design in which every AWT component has a corresponding class (a peer ) written in the underlying system's code. For example, the java.awt.Button class has a peer named java.awt.peer.Button . The peer class serves as the interface between the Java code and the computer's underlying windowing system. The methods in the peer class are written in so-called native codethat is, the non-Java code of the underlying operating system. Therefore, AWT components are inherently platform dependent.

The AWT peer model

AWT components are called heavyweight because they depend on the native (peer) system for their drawing and rendering. Since every AWT component has an associated peer component, a Java AWT component would look just like the peer component. This is why an AWT button on a Windows platform looks just like a Windows button. In effect, the AWT button, via its peer, creates and uses a Windows button. When you change the Java button's label, it must call a method in the peer class that changes the label of the peer button. This interaction between Java and the native windowing system requires a good deal of overhead, thereby affecting the overall efficiency of the system.

[Page 605]

By contrast, a lightweight component is one written entirely in Java. Instead of depending on a native component for its rendering, a lightweight component is drawn and rendered entirely by Java code. Because they do not depend on underlying system code, Swing components are more efficient and more portable than corresponding AWT components.

Lightweight components

Figures 13.1 and 13.2 show the relationship between AWT and Swing classes. The top-level Swing classes JApplet , JDialog , JFrame , and JWindow are direct subclasses of their corresponding AWT counterparts. These are the top-level GUI windows. The remaining Swing components (Fig. 13.2) are subclasses of java.awt.Component and java.awt.Container . As you can see, the names of Swing and AWT components are very similar. Swing components that have corresponding AWT components have names that begin with "J."

Figure 13.1. Swing classes, part 1: Relationship between the AWT and the top-level Swing windows.

Figure 13.2. Swing classes, part 2: Swing GUI components are derived from the `JComponent` class.

(This item is displayed on page 606 in the print version)

One might think that because Swing components are superior to their AWT counterparts, the AWT package will eventually be dropped. However, this is not likely. Even if a Java program uses Swing components exclusively, that will still not break the dependence on the AWT.

There are several reasons for this dependence. First, Swing's top-level window classes JApplet , JDialog , JFrame , and JWindow are defined as extensions to their AWT counterparts. This means that Swing-based GUIs are still dependent on the AWT. Java programs need to have some way to map their windows to the windowing system used on the native (Windows, Unix, or Macintosh) platform. The AWT's top-level windows Window , Frame , Dialog , and Panel provide that mapping.

[Page 606]

Second, the JComponent class, which is the basis for all Swing components, is derived from java.awt.Container . There are many more such dependencies. Fundamentally, Swing components are based on the AWT.

Finally, all GUI applications and applets use layout managers ( java.awt.FlowLayout ), fonts ( java.awt.Font ), colors ( java.awt. Color ), and other noncomponent classes that are defined in the AWT. There is just no way to design a GUI without using AWT classes. Therefore, the programs presented in this and subsequent chapters will use Swing components instead of corresponding AWT components, but they also will use layouts and other elements from the AWT.

Java Programming Tip: Swing Documentation