Why to use AWT

The most serious drawback of

old-style AWT, which is to be learned in this chapter, is that it has unsatisfactory performance both in object-oriented Design and GUI development package design. It brings us back to the Dark ages of programming (other words are "bad", "scary", "nasty", etc.). You must write code to execute each event, including some tasks that you can easily accomplish with resources in other environments.
Many problems like this are mitigated or eliminated in Java 1.1 because:
(1) The new AWT of Java 1.1 is a better programming model and a welcome step toward better library design. The Java beans is the framework for that library. The
(2) GUI Builder (visual programming environment) applies to all development systems. When we put components into a form using graphical tools, the Java beans and the new AWT enable the GUI builder to help us automate the code. Other component technologies, such as ActiveX, will also be supported in the same way.

So why learn to use the old AWT? The reason is simple, because its existence is a fact. For now, this fact is a bit of a disadvantage for us, and it involves an objective of object-oriented library design: Once we publish a component in a library, we can't get rid of it. If you remove it, it will damage other people's existing code. In addition, when we learn Java and all the programs that use old AWT, we find that many of the original code uses older AWT.
AWT must be able to make traffic with the GUI components of the inherent operating system, which means it needs to perform a task that a piece of the program cannot do. An untrusted piece of the program cannot make any direct calls in the operating system, otherwise it will do something inappropriate to the user's machine. An untrusted piece of the program cannot access important features. For example, the only way to "draw a window on the screen" is by invoking a standard Java library that has special interfaces and security checks. The Trust library created by the Sun's original model will only be available to the Java System Trust controller in the Web browser, and the automatic authorization will control how to get into the library.
But what happens when we want to increase the functionality of the operating system to access new components? Wait for Sun to decide that our extensions are merged into the standard Java library, but that doesn't necessarily solve our problems. The new model in Java version 1.1 is "trust code" or "signature code", so a special server officers transferred Guevara the code of the public key encryption system that we downloaded and used by the prescribed developer. So we can see where the code comes from, it's really Bob's code, or someone's pretending to be Bob's code. This does not prevent Bob from making a mistake or doing something malicious, but can prevent Bob from escaping the responsibility of making computer viruses anonymously. A digitally signed piece of the program-"Trusted Program"-can get into our machine in Java version 1.1 and control it directly, just as some other applications get "trusted" from the trust-relationship automatic Authorization machine and install it on our machine.
That's all the characteristics of old AWT. Old AWT code will always exist, and new Java programmers will encounter old AWT code when they learn from old books. In the same way, the old AWT is worth learning, for example in a routine design with few libraries. The old AWT includes a range that does not take into account depth and enumerates every program and class, instead giving us an overview of the old AWT design.