There is a vast amount of functionality in the Java class libraries devoted to supporting graphical user interface (GUI) creation and management, far more than it is feasible to cover in a single book – even if it is big. Just the JFrame class, which we will be exploring in a moment, contains more than 200 methods when one includes those inherited from superclasses! We will therefore have to be selective in what we go into in detail, in terms of both the specific classes we discuss and their methods. We will however cover the basic operations that you need to understand to create your own applications and applets. With a good grasp of the basics, you should be able to explore other areas of the Java class library beyond those discussed without too much difficulty.
The fundamental elements that you need in order to create a GUI reside in two packages, java.awt and javax.swing. The java.awt package was the primary repository for classes you would use to create a GUI in Java 1.1 – 'awt' being an abbreviation for Abstract Windowing Toolkit, but many of the classes it defines have been superseded in Java 2 by javax.swing. Most of the classes in the javax.swing package define GUI elements, referred to as Swing components, that provide much-improved alternatives to components defined by classes in java.awt. We will be looking into the JButton class in the Swing set that defines a button, rather than the Button class in java.awt. However, the Swing component classes are generally derived from, and depend on, fundamental classes within java.awt, so you can't afford to ignore these.
The Swing classes are part of a more general set of GUI programming capabilities that are collectively referred to as the Java Foundation Classes, or JFC for short. JFC covers not only the Swing component classes, such as those defining buttons and menus, but also classes for 2D drawing from the java.awt.geom package, and classes that support drag-and-drop capability in the java.awt.dnd package. The JFC also includes an API defined in the javax.accessibility package that allows applications to be implemented that provide for users with disabilities.
The Swing component classes are more flexible than the component classes defined in the java.awt package because they are implemented entirely in Java. The java.awt components depend on native code to a great extent, and are, therefore, restricted to a 'lowest common denominator' set of interface capabilities. Because Swing components are pure Java, they are not restricted by the characteristics of the platform on which they run. Apart from the added function and flexibility of the Swing components, they also provide a feature called pluggable look-and-feel that makes it possible to change the appearance of a component. You can programmatically select the look-and-feel of a component from those implemented as standard, or you can create your own look-and-feel for components if you wish. The pluggable look-and-feel of the Swing components has been facilitated by designing the classes in a particular way, called the Model View Control architecture.
The design of the Swing component classes is loosely based on something called the Model-View-Controller architecture, or MVC. This is not of particular consequence in the context of applying the Swing classes, but it's important to be aware of it if you want to modify the pluggable look-and-feel of a component. MVC is not new, and did not originate with Java. In fact the idea of MVC emerged some time ago within the context of the Smalltalk programming language. MVC is an idealized way of modeling a component as three separate parts:
The model that stores the data that defines the component.
The view that creates the visual representation of the component from the data in the model.
The controller that deals with user interaction with the component and modifies the model and/or the view in response to a user action as necessary.
In object-oriented terms, each of the three logical parts for a component – the model, the view, and the controller – is ideally represented by a different class type. In practice this turns out to be difficult because of the dependencies between the view and the controller. Since the user interacts with the physical representation of the component, the controller operation is highly dependent on the implementation of the view. For this reason, the view and controller are typically represented by a single composite object that corresponds to a view with an integrated controller. In this case the MVC concept degenerates into the document/view architecture that we introduced when we discussed the Observable class and Observer interface. Sun call it the Separable Model architecture.
The way the Swing components provide for a pluggable look-and-feel is to make the visual appearance of a component and the interface to the user the responsibility of an independent object called the UI delegate. This is the view+controller part of the MVC model. Thus a different UI delegate can provide a component with a new look-and-feel.
The details of how you modify the look-and-feel of a component is beyond the scope of this book. It is, however, as well to be aware of the MVC architecture on which the Swing components are based since it appears quite often in the literature around Java, and should you want to change the look-and-feel of a component at some time.