Section 16.3. Stompin at the Savoy, or The Swing Paradigm

16.3. Stompin' at the Savoy, or The Swing Paradigm

When we say "Swing," we generally mean the set of classes in the javax.swing package and its subpackages (such as javax.swing.table). The packages are libraries of code that give you predefined classes from which you can construct a GUI for your application. The programs you write will be written in Java, the syntax will look like Java, but there will be a lot of creation of classes, uses of interfaces, implementations of abstract classes, and a variety of method calls that all deal with these Swing classes.

So what's going on with all this stuff? What can we expect to do, see, write? In most applications that a programmer writes, it is the job of the programmer to design and write the code for the main execution path of the program. "Yes, every program has a beginning, middle, and an end" (with apologies to "Seymour and his frozen yoghurt stand," from Sesame Street). But it's not quite the same with Swing. While it does have to have a beginning, middle, and end (these are, after all, basic Von Neumann architecture machines), the big difference is that you do not have to write most of the control logic; it comes as part of the Swing set.

Look at it this way. With Swing, as with other GUI toolkits, you don't have to write code to deal with the mouse, keyboard shortcuts, or painting characters onto a graphical screen. You don't have to write all the code associated with a button press, because, while it seems simple enough, a button press is really a quite complex user interaction, involving repainting of the button's border, possibly its shading or changing its icon, coordinating that with the mouse presses and releases, and deciding whether the releases happen within or without the boundaries of the buttonall this and more, just for a simple button press. All this has been done for you, and packaged up into Swing classes.

So what is left for you to do? You have to:

• Construct the various items that will appear on the screen (in one or more windows).

• Specify the location of these objects in the windows (layout).

• Provide snippets of code that are the actions associated with various events (events happen, for example, when a button is pressed or a mouse is clicked). These actions are the guts of the code that make your application behave how you want.

Remember, some behaviors are enforced by the GUI as part of standard "look and feel." Some things, like layout, are up to you to do well so long as you keep within the standard UI guidelines. And some is just specific to your application.

With that in mind, let's walk through the "Hello, world" example for a brief description of what each line does.

We begin with some import statements, to resolve references to both Swing and AWT classes. Swing is built on top of AWT, so some of the classes that you use will actually be AWT classes. The biggest difference this makes to you is in the import statements.

We then begin our class declaration, followed by the definition of the only method in this class, main(). Swing applications will typically have other methods, but for our simple example we only need this one.

Now comes some real Swing. The creation of a JFrame object is very important. In Swing we need to have containers to hold the objects that we want to display. The JFrame is a top-level container, one specifically meant to hold other objects, but also meant to be the first one of a containment hierarchy. (There are only three such top-level containers in Swing: JFrame, JDialog, and JApplet.)

Next we create a JLabel. It's a Swing object meant to hold small amounts of text. The text can be either constant or changing, but it's not user-editable (that would be a different kind of Swing object).

We add the label to the frame, so that when the window (the JFrame) appears, it will show our text inside.

The setDefaultCloseAction() does what you think. When you press the X in the upper right of the window frame (or wherever your window manager puts it), then not only will the window go away, but the program will stop running. (This is not the standard default value since JFrames can contain other JFrames, and for most frames you wouldn't want closing the frame to quit the program.)

When we "pack" the frame, that's when the real magic happens. It kicks off the GUI activity on a separate thread, but also packs the various pieces that we've added to the frame, sizing them as best it can to fit into the frame, and sizing the frame to hold all the pieces. We see little of that with our example, which has only one label.

As an aside, pack() is inherited from awt.Window, which describes the "magic" thus:

A component is displayable when it is connected to a native screen resource. A component is made displayable either when it is added to a displayable containment hierarchy or when its containment hierarchy is made displayable. A containment hierarchy is made displayable when its ancestor window is either packed or made visible.

So pack()-ing the frame connects it to a "native screen resource," which effectively gets the whole GUI thing going.

And now back to the business at hand.

Finally, the setVisible() call makes the window appear. Then the main() is done. In case you're wondering, go ahead and put a System.out.println() message after the setVisible(). It will be printed right away. The main() has ended; the GUI activity is happening on another thread.