Question

对于本章要学习的“老式”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 设计的概貌。