Start Concurrent: A Gentle Introduction to Concurrent Programming

Java provides an ActionListener interface. This interface has a single method named actionPerformed(). This method takes an ActionEvent as input and performs a suitable action based on the event. A JButton object generates ActionEvent when it’s pressed. Any class that implements the ActionListener interface can be registered as an action listener on a JButton or any other component that generates an ActionEvent.

As discussed in Chapter 10, an interface is a set of method signatures. If a class implements an interface, it promises that its objects will have all of the methods in that interface. If a class implements ActionListener, it’s saying that it knows what to do when an action is performed. The following statements show how to add an ActionListener to a button and implement its actionPerformed() method.

The first line above creates a button named thisButton. The remaining code adds an action listener to the button. The process of adding an action listener to an object is also known as registering a listener on the object. Note that the sole argument to this addActionListener() method is a newly created ActionListener object. Inside this newly created and anonymous ActionListener object, we implement the actionPerformed() method. Whatever code we want to execute in response to the clicking of the thisButton button goes inside the actionPerformed() method.

This syntax may look strange to you. ActionListener is an interface, which can’t be instantiated. What’s that new keyword doing? It’s doing something pretty amazing by creating an instance of an anonymous class. On the fly, we’re creating a class that has never existed before. It doesn’t even have a name! All we know about it is that it implements the interface ActionListener.

Note that there are braces after the constructor call, defining what’s inside of this class. Inside, we have only created an actionPerformed() method, but we could have created fields as well as other methods. It’s a little ugly to create a whole new class and instantiate it in the middle of calling the addActionListener() method, but it’s also very convenient. We need to supply an object that reacts to the event exactly the way we want it to. Since one doesn’t exist yet, we have to create it. Of course, it’s possible to supply any object that implements the ActionListener interface, not just instances of anonymous classes. For more information about nested classes, inner classes, and anonymous classes, refer to Section 9.4 and Section 10.4.

There are a few differences between Program 15.3 and Program 15.4. In the second program, most of the code has been moved from the main() method to the constructor. Various objects, namely the frame, the panel, all three buttons, and the text box are now fields of the object instead of local variables in the main() method. The buttons need to be fields so that the actionPerformed() method can compare against them, and the text box needs to be a field so that the method can change it.

We’ve examined two styles of adding an ActionListener to a Java program. The choice of style depends on your needs. Adding an anonymous ActionListener to each component makes it easy to specify an action for each one, but the syntax is ugly. Using a named class (often the main program class or a subclass of JFrame) as the ActionListener allows you to handle many events in a centralized location. It can be easier to find errors when all events are handled in one actionPerformed() method, but the method can become complex since it needs to determine which component generated the event.

An ItemListener can be attached to a component such as a check box or a radio button to listen for when it’s selected or deselected. When you select a check box, a ✓ sign appears to its left, and an ItemEvent is generated. When you select an already checked check box, the sign disappears, and another ItemEvent is generated.

Creating a check box is very much like creating a button, except that we use the JCheckBox component instead of JButton. When it’s initially created, a check box is unchecked.

Just as the ActionListener interface only has a single method, the ItemListener interface only has one as well, itemStateChanged(), which takes a single parameter of type ItemEvent.

An ActionEvent and an ItemEvent are similar, but one reason that Java has two different interfaces with two different kinds of events is because an ItemEvent has more information: By using the getStateChange() method, it’s possible to tell whether the component that fired the ItemEvent is now selected or deselected.

Below is an example of a GUI with three check boxes.

Another Swing component that can be used with an ItemListener is JRadioButton. Radio buttons are similar to check boxes in that clicking one will select it. However, radio buttons are almost always used in a group. When one radio button in the group is selected, all others are deselected, guaranteeing that only one radio button can be selected at a time.

For example, the following code will create three radio buttons, only one of which can be selected.

The ButtonGroup object provides the logical grouping that guarantees a maximum of one JRadioButton will be selected. This grouping is only for the purposes of selection, and the radio buttons still need to be added to a panel or a frame or some other GUI container to display them.

With check boxes, an ItemListener didn’t provide much of an advantage over an ActionListener. A radio button, however, can be deselected not by clicking on it but by clicking on another radio button. Thus, using an ItemListener allows us to handle the event when a radio button is deselected, even though it wasn’t clicked itself, as illustrated in the following example.

Clicking a button or a check box is useful, but a mouse can generate events in other ways too. For example, in a screen full of pictures, you might want to highlight a picture when the cursor hovers over it. Or you might want to create a drawing program which uses a mouse as a pen. To process general mouse events, we need an object that implements the MouseListener interface, which defines the following methods.

The function of each method is implied by its name. The mouseEntered() event fires when the mouse cursor moves into the area above a component. Conversely, the mouseExited() event fires when a mouse cursor was over a component and has just moved away. The mousePressed() event fires when a mouse button is pressed over a component. The mouseReleased() event fires when a mouse button is released over a component. The mouseClicked() event is a combination of both the mousePressed() and mouseReleased() events, occurring only if a mouse button was pressed and then released while the cursor was over a component. As you can see, a component only fires events when the cursor is over it (or has just left). Thus, a component only reports events that have to do with it, not the general state of the mouse.

Each method in MouseListener receives a MouseEvent object as its argument. To handle mouse events, a class must implement the MouseListener interface. Doing so is similar to the implementation of the ActionListener interface from the previous section, but implementing MouseListener requires a definition for each of the five methods listed above. The next example illustrates MouseListener in use.

Creating a MouseListener requires all five methods in the interface to be implemented. In many cases, as in Example 15.7, there’s no need to implement all the methods because we’re not interested in all the corresponding events. In such situations we’re forced to include empty methods. However, you might want to include the methods only when they’re needed. The MouseAdapter class helps us avoid implementing methods we don’t need.

MouseAdapter is an abstract class, unlike the MouseListener interface. The advantage of using MouseAdapter is that it already provides a skeletal implementation of each method needed to process mouse events. We can override these implementations as needed, and we don’t need to provide an implementation of a method that’s not used.

In this chapter we describe three types of listeners in Java, ActionListener, ItemListener and MouseListener. You may have noticed that none of the mouse events we discussed involved the movement of the mouse inside of the component, only whether it was entering or exiting the component. Because tracking mouse movement is more computationally expensive than tracking simple presses, releases, enters, and exits, Java uses yet another listener to handle mouse movement, MouseMotionListener. It contains the methods mouseDragged() and mouseMoved(), which are used to handle mouse movement with or without the button pressed.

Java provides several other listeners to handle a variety of events. For example, the DocumentListener can be attached to a JTextField or a JTextArea object to listen to document events, which include the insertUpdate() event that’s fired when a character is inserted the text box. A KeyListener can also be attached to text boxes to listen to key events such as the return key being typed, which can have similar functionality. These events could be useful when developing a text editor application, for example.

After you’ve mastered the contents of this chapter, you may plan to write more complex GUIs than the ones we discuss. For further information, you might want to follow the Java tutorial on writing event listeners at the Oracle Swing Events tutorial site.

There are many ways to play sounds in Java, but the simplest is through the Clip interface. Let’s see how we can create an appropriate Clip object.

This statement creates a new Clip object using a static method from the AudioSystem class in the javax.sound.sampled package. To use clip, we need an audio file to play.

This command will play the clip in clip loaded from the specified file, exactly once. If you want to play the clip in a loop, use the loop() method. You can specify a specific number of times to loop or use the Clip.LOOP_CONTINUOUSLY constant to make it loop an unlimited number of times.

To stop a clip from playing, use the stop() method.

Now that we’ve seen how to create, open, play, and stop an audio clip, we’re ready to write a program that can play sounds.

Images are often useful when creating GUIs. In this section we show you how to use images to create icons and then use those icons to decorate buttons and labels. First, let’s see how an icon object can be created. Suppose we have a picture file named smile.jpg in a directory named pictures. Note that the pictures directory should be located in same directory as the class files for your program. The following statement creates an object of type ImageIcon from this picture.

The file name, along with its path, is passed to the ImageIcon constructor as a string. Now we can add the image to a button.

Similarly, you can add an image to a label. The next example gives a simple program that creates a button with an image.

In some applications you might want to show a picture with an attached text label. For example, a shopping cart application for an online clothing store might shows pictures of clothes, each labeled with a name and a price. The JLabel class is flexible, able to display text alone, an image alone, or both. However, a JLabel is designed for displaying information and can’t read user input.

Here are three different ways to create a label.

The first JLabel constructor above creates a label displaying only text, namely, “Text only.” The second constructor creates a label decorated with an icon created from a picture. The third constructor creates a label with the same icon and additional text. The last argument in this third case is JLabel.CENTER, a constant that specifies that the content of the label (both the image and the text) should be placed horizontally in the center of the label. A horizontal alignment of left or right could also be specified using the constants JLabel.LEFT or JLabel.RIGHT, respectively.

Sometimes you might want to place the text below the icon that decorates the label. To do so, you could set the horizontal and vertical positions of the text as follows.

The FlowLayout manager is one of simplest. When a container is using the FlowLayout manager, components will be added in order from left to right. When there’s no more space, subsequent components will be added starting on the next row. In addition, each row of components is centered within the container. The JPanel container uses FlowLayout by default, but it’s possible to set it explicitly as well.

When we’ve added more than one component to a JFrame in previous examples, we’ve first added them to a JPanel. The reason we did so is because FlowLayout is the default layout manager for JPanel containers. Although every JFrame has a container, it uses the BorderLayout manager by default, which would have complicated our earlier examples. The next example illustrates FlowLayout further.

The GridLayout manager lays out components in a grid with a set number of rows and columns. As with other layout managers, GridLayout can be applied to frames and panels.

This snippet creates a frame named frame and sets its layout manager to GridLayout. The first two arguments to GridLayout give the number of rows and columns, respectively. The last two arguments (which are optional) give the horizontal and vertical gaps between the neighboring cells in the grid. In this example the frame will contain a total of six cells organized into three rows with two columns.

Figure 15.12 shows how frame will look after six buttons, labeled 0 through 5, have been added to it in order. The buttons were created in the same way as the buttons in Program 15.10, but they look different because of the GridLayout manager. A key feature of using GridLayout is that all cells in the grid will be the same size and will stretch to fill the entire container. Also note the equal spacing between the neighboring cells. It’s possible to add more cells or fewer cells than specified in the GridLayout constructor, but the layout manager will be forced to guess at your intentions.

The BorderLayout manager is the default one for a JFrame. It allows components to be laid out spatially in regions of a container. These regions are north, south, east, west, and center. This layout is intuitively easy to understand, but it’s difficult to describe precisely.

You can only add one component to each region of the layout, and adding a component to any region is optional. The regions will stretch or shrink to accommodate the components inside. The north and south regions will only be as tall as needed to hold their contents, but their width will stretch as wide as the entire container. The east and west regions will only be as wide as needed to hold their contents, but their height will stretch as tall as needed to fit the remaining height of the container. Both the height and the width of the center region will stretch as big as it needs to fill the container.

At first glance, BorderLayout seems that it would rarely be useful. However, this layout is frequently used because it establishes a spatial relationship between different parts of a GUI. A container with a BorderLayout generally has other containers with their own layouts added to its regions, as shown in the following example.

There’s no limit to how deeply you can nest containers within each other. Sometimes you must use many BorderLayout managers to achieve the appearance you want. The value of establishing these spatial relationships is that they’re still valid even when the GUI is resized. Even so, it’s challenging to make a usable GUI that looks attractive no matter how the user resizes it or what the resolution of the user’s screen is.

Although there’s not enough space here to discuss strategies for developing attractive GUIs, it’s worth noting the value of the setPreferredSize() method that all components have. This method is one of the best ways to suggest a size for particular components, especially if other components and containers are going to stretch as needed. When key components have their sizes set using setPreferredSize(), the entire frame can be packed using the pack() method, which sizes the frame to fit its components.

The three layout managers discussed in this section are the simplest, but there are others. The BoxLayout manager is a useful tool for laying out components in a line, whether horizontal like a row or vertical like a column. The GridBagLayout manager can be used to create complex layouts in a single container using a grid-based framework that’s much more flexible than GridLayout, but the complexity of programming GridBagLayout is significant. The SpringLayout and GroupLayout managers are also powerful, but they’re designed for use with a GUI builder utility.

To use menus we have to create a menu bar.

This statement creates an object of type JMenuBar named menuBar which can hold menus. A JFrame has only one menu bar. We can create several menus and add them to the menu bar.

These statements create two menus named frenchMenu and germanMenu labeled “French Menu” and “German Menu,” respectively. The two menus can be added to the existing menu bar using the add() method. Menus can be populated with menu items as follows.

These statements create two menu items named coqAuVin and moulesFrites. These menu items are then added to the menu frenchMenu. After having created a menu bar together with its menus and their respective menu items, we need a frame so that we can set its menu bar to the one we created.

These statements create a frame and set its menu bar to menuBar. It’s possible to use the add() method instead of the setJMenuBar() method to add a JMenuBar to a JFrame. However, doing so will add the JMenuBar to the regular content area, not to the menu area.

Figure 15.16 shows a GUI with the menus and menu items added above.

Sometimes you might need to disable a menu item and enable it only under certain conditions.

These statements create a menu item named unusable and disable it. A disabled menu item shows as a gray item and doesn’t respond to attempts to select it. As we showed in Example 15.9, JButton objects, like many other components, can be disabled in the same way.

An action listener can be added to each menu item, just like a JButton. Then, when a menu item is clicked by the user, an action event is generated. A JCheckBoxMenuItem object can be added to a JMenu as well. This object will have a check box which can be selected or unselected. A regular JMenuItem object generates an ActionEvent which is handled by an ActionListener. Like a JCheckBox, a JCheckBoxMenuItem can also generate an ItemEvent handled by an ItemListener. Here are examples of both situations.

A JMenuItem works just like a JButton. In fact, the same action listener code could handle events for both buttons and menu items. Similar to JCheckBox objects, a JCheckBoxMenuItem can be handled with an ActionListener if you only want to know when it’s clicked on. However, you can add an ItemListener if you want to write an event handler that runs whenever the state of its check box changes.