Swing is Java’s graphical user interface toolkit. The
javax.swing package (and its numerous subpackages)
contain classes representing interface items such as windows, buttons, combo
boxes, trees, tables, and menus—everything you need to build a modern, rich
Swing, the pure Java user interface toolkit
Accessibility, which provides tools for integrating nonstandard input and output devices into your user interfaces
The 2D API, a comprehensive set of classes for high-quality drawing
Drag and Drop, an API that supports the drag-and-drop metaphor
JFC is one of the largest and most complex parts of the standard Java platform, so it shouldn’t be any surprise that we’ll take several chapters to discuss it. In fact, we won’t even get to talk about all of it, just the most important parts—Swing and the 2D API. Here’s the lay of the land:
This chapter covers the basic concepts you need to understand how to build user interfaces with Swing.
Chapter 17 discusses the basic components from which user interfaces are built: buttons, lists, text fields, checkboxes, and so on.
Chapter 18 dives further into the Swing toolkit, describing text components, trees, tables, and other advanced components.
Chapter 19 discusses layout managers, which are responsible for arranging components within a window.
Chapter 20 discusses the fundamentals of drawing, including simple image display.
Chapter 21 covers the image generation
and processing tools of the
java.awt.image package. We’ll throw in audio
and video for good measure.
We can’t cover the full functionality of Swing in this book; if you
want the whole story, see Java
Swing by Marc Loy, Robert Eckstein, Dave Wood, Brian
Cole, and James Elliott (O’Reilly). Instead, we’ll cover the basic tools you
are most likely to use and show some examples of what can be done with some
of the more advanced features. Figure 16-1
shows the user interface component classes of the
To understand Swing, it helps to understand its predecessor, AWT. As its name suggests, AWT is an abstraction. Like the rest of Java, it was designed to be portable; its functionality is the same for all Java implementations. However, people generally expect their applications to have a consistent look and feel and that is usually different on different platforms. So AWT was designed to provide the same functionality on all platforms, yet have the appearance of a native application. The idea is that you could choose to write your code under Windows, then run it on an X Window System or a Macintosh and get more or less the native look and feel on each platform for free.To achieve platform binding, AWT uses interchangeable toolkits that interact with the host windowing system to display user interface components. This shields the Java application from the details of its environment in which it’s running and keeps the APIs pure. Let’s say you ask AWT to create a button. When your application or applet runs, a toolkit appropriate to the host environment renders the button appropriately: on Windows, you can get a button that looks like other Windows buttons; on a Macintosh, you can get a Mac button; and so on.
AWT had some serious shortcomings, however. The worst was that the use of platform-specific toolkits meant that AWT applications might be subtly incompatible on different platforms. Furthermore, AWT lacked advanced user interface components, such as trees and grids, which were not common to all environments. AWT provided the desired look and feel, but limited the features and true portability of Java GUI applications.
Swing takes a fundamentally different approach. Instead of using native toolkits to supply interface items, such as buttons and combo boxes, components in Swing are implemented in Java itself. This means that, whatever platform you’re using, by default a Swing button (for example) looks the same. However, Swing also provides a powerful, pluggable look-and-feel API that allows the native operating system appearance to be rendered at the Java level. Working purely in Java makes Swing much less prone to platform-specific bugs, which were a problem for AWT. It also means that Swing components are much more flexible and can be extended and modified in your applications in ways that native components could never be.
Working with user interface components in Swing is meant to be easy. When building a user interface for your application, you’ll be working with a large set of prefabricated components. It’s easy to assemble a collection of user interface components (buttons, text areas, etc.) and arrange them inside containers to build complex layouts. However, when necessary, you can build upon these simple components to make entirely new kinds of interface gadgets that are completely portable and reusable.
Swing uses layout managers to arrange components inside containers and control their sizing and positioning. Layout managers define a strategy for arranging components instead of specifying absolute positions. For example, you can define a user interface with a collection of buttons and text areas and be reasonably confident that it will always display correctly, even if the user resizes the application window. It doesn’t matter what platform or user interface look-and-feel you’re using; the layout manager should still position them sensibly with respect to each other.
The next two chapters contain examples using most of the components in
javax.swing package. Before we dive
into those examples, we need to spend some time talking about the concepts
Swing uses for creating and handling user interfaces. This material should
get you up to speed on GUI concepts and how they are used in Java.