對於本章要學習的“老式”AWT，它最嚴重的缺點就是它無論在面向對象設計方面，還是在GUI開發包設計方面，都有不盡如人意的表現。它使我們回到了程序設計的黑暗年代（換成其他話就是“拙劣的”、“可怕的”、“惡劣的”等等）。必須為執行每一個事件編寫代碼，包括在其他環境中利用“資源”即可輕松完成的一些任務。
許多象這樣的問題在Java 1.1裡都得到了緩解或排除，因為：
(1)Java 1.1的新型AWT是一個更好的編程模型，並向更好的庫設計邁出了可喜的一步。而Java Beans則是那個庫的框架。
(2)“GUI構建器”（可視編程環境）將適用於所有開發系統。在我們用圖形化工具將組件置入窗體的時候，Java Beans和新的AWT使GUI構建器能幫我們自動完成代碼。其它組件技術如ActiveX等也將以相同的形式支持。
既然如此，為什麼還要學習使用老的AWT呢？原因很簡單，因為它的存在是個事實。就目前來說，這個事實對我們來說顯得有些不利，它涉及到面向對象庫設計的一個宗旨：一旦我們在庫中公布一個組件，就再不能去掉它。如去掉它，就會損害別人已存在的代碼。另外，當我們學習Java和所有使用老AWT的程序時，會發現有許多原來的代碼使用的都是老式AWT。
AWT必須能與固有操作系統的GUI組件打交通，這意味著它需要執行一個程序片不可能做到的任務。一個不被信任的程序片在操作系統中不能作出任何直接調用，否則它會對用戶的機器做出不恰當的事情。一個不被信任的程序片不能訪問重要的功能。例如，“在屏幕上畫一個窗口”的唯一方法是通過調用擁有特殊接口和安全檢查的標准Java庫。Sun公司的原始模型創建的信任庫將僅僅供給Web浏覽器中的Java系統信任關系自動授權器使用，自動授權器將控制怎樣進入到庫中去。
但當我們想增加操作系統中訪問新組件的功能時該怎麼辦？等待Sun來決定我們的擴展被合並到標准的Java庫中，但這不一定會解決我們的問題。Java 1.1版中的新模型是“信任代碼”或“簽名代碼”，因此一個特殊服務器將校驗我們下載的、由規定的開發者使用的公共密鑰加密系統的代碼。這樣我們就可知道代碼從何而來，那真的是Bob的代碼，還是由某人偽裝成Bob的代碼。這並不能阻止Bob犯錯誤或作某些惡意的事，但能防止Bob逃避匿名制造計算機病毒的責任。一個數字簽名的程序片——“被信任的程序片”——在Java 1.1版能進入我們的機器並直接控制它，正像一些其它的應用程序從信任關系自動授權機中得到“信任”並安裝在我們的機器上。
這是老AWT的所有特點。老的AWT代碼將一直存在，新的Java編程者在從舊的書本中學習時將會遇到老的AWT代碼。同樣，老的AWT也是值得去學習的，例如在一個只有少量庫的例程設計中。老的AWT所包括的范圍在不考慮深度和枚舉每一個程序和類，取而代之的是給了我們一個老AWT設計的概貌。
