Why use the AWT?

Bruce Eckel’s Thinking in Java Contents | Prev | Next

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
everything,
including tasks that are accomplished much more easily using resources
in other environments.

  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:
Once
you publicize a component in your library, you can never take it out
.
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
can
reach into your machine and manipulate it directly, just like any other
application you get from a “trusted” vendor and install onto your
computer.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read