The
original design goal of the graphical user interface (GUI) library in Java 1.0
was to allow the programmer to build a GUI that looks good on all platforms.
That
goal was not achieved. Instead, the Java 1.0Abstract
Window Toolkit
(AWT) produces a GUI that looks equally mediocre on all systems. In addition
it’s restrictive: you can use only four fonts and you cannot access any
of the more sophisticated GUI elements that exist in your operating system
(OS). The Java 1.0 AWT programming model is also awkward and non-object-oriented.
Much
of this situation has been improved with the Java 1.1
AWT event model, which takes a much clearer, object-oriented approach, along
with the introduction of Java Beans, a component programming model that is
particularly oriented toward the easy creation of visual programming
environments. Java 1.2
finishes the transformation away from the old Java 1.0 AWT by adding the Java
Foundation Classes
(JFC), the GUI portion of which is called “Swing.”
These are a rich set of easy-to-use, easy-to-understand Java Beans that can be
dragged and dropped (as well as hand programmed) to create a GUI that you can
(finally) be satisfied with. The “revision 3” rule of the software
industry (a product isn’t good until revision 3) seems to hold true with
programming languages as well.
One
of Java’s primary design goals is to create
applets,
which are little programs that run inside a Web browser. Because they must be
safe, applets are limited in what they can accomplish. However, they are a
powerful tool in supporting client-side programming, a major issue for the Web.
Programming
within an applet is so restrictive that it’s often referred to as being
“inside the sandbox,” since you always have someone – the
Java run-time security system – watching over you. Java 1.1
offers digital signing for applets so you can choose to allow trusted applets
to have access to your machine. However, you can also step outside the sandbox
and write regular applications, in which case you can access the other features
of your OS. We’ve been writing regular applications all along in this
book, but they’ve been
console
applications
without any graphical components. The AWT can also be used to build GUI
interfaces for regular applications.
In
this chapter you’ll first learn the use of the original “old”
AWT, which is still supported and used by many of the code examples that you
will come across. Although it’s a bit painful to learn the old AWT,
it’s necessary because you must read and maintain legacy code that uses
the old AWT. Sometimes you’ll even need to write old AWT code to support
environments that haven’t upgraded past Java 1.0.
In the second part of the chapter you’ll learn about the structure of the
“new” AWT in Java 1.1
and see how much better the event model is. (If you can, you should use the
newest tools when you’re creating new programs.) Finally, you’ll
learn about the new JFC/Swing components, which can be added to Java 1.1 as a
library – this means you can use the library without requiring a full
upgrade to Java 1.2.
Most
of the examples will show the creation of applets, not only because it’s
easier but also because that’s where the AWT’s primary usefulness
might reside. In addition you’ll see how things are different when you
want to create a regular application using the AWT, and how to create programs
that are both applets and applications so they can be run either inside a
browser or from the command line.
Please
be aware that this is not a comprehensive glossary of all the methods for the
described classes. This chapter will just get you started with the essentials.
When you’re looking for more sophistication, make sure you go to your
information browser to look for the classes and methods that will solve your
problem. (If you’re using a development environment your information
browser might be built in; if you’re using the Sun JDK then you use your
Web browser and start in the java root directory.) Appendix F lists other
resources for learning library details.