Why use the AWT?

One

of the problems with the “old” AWT that you’ll learn about in

this chapter is that it is a poor example of both object-oriented design and

GUI development kit design. It throws us back into the dark ages of programming

(some suggest that the ‘A’ in AWT stands for “awkward,”

“awful,” “abominable,” etc.). You must write lines of

code to do

,

including tasks that are accomplished much more easily using

Many

of these problems are reduced or eliminated in

1. The
   new AWT in Java 1.1 is a much better programming model and a significant step
   towards a better library. Java Beans is the framework for that library.
2. “GUI
   builders” (visual
   programming environments) will become
   de
   rigeur
   
   for all development systems. Java Beans and the new AWT allow the GUI builder
   to write code for you as you place components onto forms using graphical tools.
   Other component technologies such as ActiveX will be supported in the same
   fashion.

So

why learn to use the old AWT? “Because it’s there.” In this

case, “there” has a much more ominous meaning and points to a tenet

of object-oriented library design:

.

If you do, you’ll wreck somebody’s existing code. In addition,

there are many existing code examples out there that you’ll read as you

learn about Java and they all use the old AWT.

The

AWT must reach into the GUI components of the native OS, which means that it

performs a task that an applet cannot otherwise accomplish. An untrusted applet

cannot make any direct calls into an OS because otherwise it could do bad

things to the user’s machine. The only way an untrusted applet can access

important functionality such as “draw a window on the screen” is

through calls in the standard Java library that’s been specially ported

and safety checked for that machine. The original model that Sun created is

that this “trusted library” will be provided only by the trusted

vendor of the Java system in your Web browser, and the vendor will control what

goes into that library.

But

what if you want to extend the system by adding a new component that accesses

functionality in the OS? Waiting for Sun to decide that your extension should

be incorporated into the standard Java library isn’t going to solve your

problem. The new model in Java 1.1 is “trusted code” or

“signed code” whereby a special server verifies that a piece of

code that you download is in fact “signed” by the stated author

using a public-key encryption system. This way, you’ll know for sure

where the code comes from, that it’s Bob’s code and not just

someone pretending to be Bob. This doesn’t prevent Bob from making

mistakes or doing something malicious, but it does prevent Bob from shirking

responsibility – anonymity is what makes computer viruses possible. A

digitally signed applet – a “trusted applet” – in Java

1.1

reach into your machine and manipulate it directly, just like any other

application you get from a “trusted” vendor and install onto your

computer.

But

the point of all this is that the old AWT is

.

There will always be old AWT code floating around and new Java programmers

learning from old books will encounter that code. Also, the old AWT is worth

studying as an example of poor library design. The coverage of the old AWT

given here will be relatively painless since it won’t go into depth and

enumerate every single method and class, but instead give you an overview of

the old AWT design.

|

|