14:
Creating Windows
& Applets
A fundamental design guideline is “make simple things easy, and difficult things possible.” [74]
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.0 Abstract Window Toolkit (AWT) produced a GUI that looked equally mediocre on all systems. In addition, it was restrictive; you could use only four fonts and you couldn’t access any of the more sophisticated GUI elements that exist in your operating system. The Java 1.0 AWT programming model is also awkward and non-object-oriented. A student in one of my seminars (who had been at Sun during the creation of Java) explained why: The original AWT had been conceptualized, designed, and implemented in a month. Certainly a marvel of productivity, and also an object lesson in why design is important.
The situation improved with the Java 1.1 AWT event model, which takes a much clearer, object-oriented approach, along with the addition of JavaBeans, a component programming model that is oriented toward the easy creation of visual programming environments. Java 2 (JDK 1.2) finished the transformation away from the old Java 1.0 AWT by essentially replacing everything with 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 JavaBeans 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.
This chapter does not cover anything but the modern Java 2 Swing library and makes the reasonable assumption that Swing is the final destination GUI library for Java.[75] If for some reason you need to use the original “old” AWT (because you’re supporting old code or you have browser limitations), you can find that introduction in the first edition of this book, downloadable at www.BruceEckel.com (also included on the CD ROM bound with this book) Note that some AWT components remain in Java, and in some situations you must use them.
Early in this chapter, you’ll see how things are different when you want to create an applet versus a regular application using Swing, 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. Almost all the GUI examples in this book will be executable as both applets and applications.
Please be aware that this is not a comprehensive glossary of either all the Swing components or all the methods for the described classes. What you see here is intended to be simple. The Swing library is vast, and the goal of this chapter is only to get you started with the essentials and comfortable with the concepts. If you need to do more, then Swing can probably give you what you want if you’re willing to do the research.
I assume here that you have downloaded and installed the JDK library documents in HTML format from java.sun.com and will browse the javax.swing classes in that documentation to see the full details and methods of the Swing library. Because of the simplicity of the Swing design, this will often be enough information to solve your problem. There are numerous (rather thick) books dedicated solely to Swing, and you’ll want to go to those if you need more depth, or if you want to modify the default Swing behavior.
As you learn about Swing, you’ll discover:
- Swing is a much better
programming model than you’ve probably seen in other languages and
development environments. JavaBeans (which will be introduced toward the end of
this chapter) is the framework for that library.
- “GUI builders” (visual programming environments) are a de
rigueur aspect of a complete Java development environment. JavaBeans and
Swing allow the GUI builder to write code for you as you place components onto
forms using graphical tools. This not only rapidly speeds development during GUI
building, but it allows for greater experimentation and thus the ability to try
out more designs and presumably come up with a better one.
- The simplicity and well-designed nature of Swing means that even if you do
use a GUI builder rather than coding by hand, the resulting code will still be
comprehensible; this solves a big problem with GUI builders from the past, which
could easily generate unreadable code.
Much of what you’ll like about Swing could be called “orthogonality of use.” That is, once you pick up the general ideas about the library, you can apply them everywhere. Primarily because of the standard naming conventions, much of the time that I was writing these examples I could guess at the method names and get it right the first time without looking anything up. This is certainly the hallmark of a good library design. In addition, you can generally plug components into other components and things will work correctly.
For speed, all the components are “lightweight,” and Swing is written entirely in Java for portability.
Keyboard navigation is automatic; you can run a Swing application without using the mouse, and this doesn’t require any extra programming. Scrolling support is effortless; you simply wrap your component in a JScrollPane as you add it to your form. Features such as tool tips typically require a single line of code to use.
Swing also supports a rather radical feature called “pluggable look and feel,” which means that the appearance of the UI can be dynamically changed to suit the expectations of users working under different platforms and operating systems. It’s even possible (albeit difficult) to invent your own look and feel.
The basic applet
Java has the ability 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, applets are a powerful tool that support client-side programming, a major issue for the Web.
