Sidebar 3.3 AWT and Swing
Java provides an extensive framework for building graphical user interfaces
(GUIs), which includes several important packages such as Abstract Windows
Toolkit (AWT), Swing, Java Beans, and Java3D.
The Java AWT and Swing packages consist of four main categories of classes:
components, containers, events and event listeners. Components and containers
are the visual building blocks of graphical user interfaces. They define the visual
characteristics of the GUI. Events, event listeners and event handlers represent
user inputs and define the GUI behaviour in response to them.
Components . Commonly used Swing classes are JButton and JCheckBox ,
JComboBox , JLabel , JList , JScrollbar , JtextField and JTextArea . All of these classes
are customizable by defining specific values for their properties, such as the dis-
played label, the position, the dimension, the background colour, the border
shape, etc. Usually, these classes do not need to be extended by inheritance.
Containers . Commonly used Swing classes are JPanel , JApplet , JFrame and
JDialog . Usually these classes need to be customized by deriving problem-
specific subclasses. Concrete subclasses define which visual components build
up the GUI, how they interact and how they respond to user inputs. For most
programs, the top-level Swing container is a subclass of JFrame or JApplet . Both
of them implement a single main window.
Events . Commonly used AWT classes are ActionEvent , ItemEvent , KeyEvent and
MouseEvent . These classes represent user inputs and usually do not need to be
customized at all.
Event listeners . The AWT package offers a variety of event listener interfaces,
such as ActionListener , MouseListener , MouseMotionListener , etc. Every class that
is interested in processing an event has to implement the corresponding event
listener interface. Instances of this class must be registered with a component
(e.g. a button). When the event occurs, the relevant method in the listener
object is invoked. The AWT package implements a number of abstract classes
that implement event listener interfaces, such as the classes MouseAdapter and
MouseMotionAdapter . These classes define common methods for handling
typical input events. Concrete subclasses overload these methods in order to
express the desired behaviours.
Two major aspects of the scheduling tool need to be tested: the scheduling
algorithm and the graphical user interface. We adopt the following strategy:
First we test the graphical interface in order to verify the correct corre-
spondence between the data that are visualized and the actual temporal
and performance values of the time plan. This can be done by inserting in
the code above a few debug commands that display on the screen the
textual representation of task and resource parameters. Thus, the test
might consist in a set of experiments that verifies all the edit and revise
functionalities of the graphical interface.
Then we test the scheduling algorithm with data that represent the fitness