Application Security Testing: An Integral Part of DevOps
|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.