Digg
del.icio.us
Newsvine
Facebook
Google
LinkedIn
MySpace
Reddit
Slashdot
StumbleUpon
Technorati
Twitter
Windows Live
YahooBuzz
FriendFeedWhy use the AWT?
Posted
on March 1st, 2001
| 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.
- 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.
- “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.
But
the point of all this is that the old AWT is
there.
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.
Comments
There are no comments yet. Be the first to comment!