【IT168 技术文章】众所周知，Java 语言在服务器上以及 applet 领域已经非常成功了，但是它在最终用户应用程序领域为什么没有大行其道呢?有几个原因。首先，即使很小的应用程序的内存占用通常也有好几兆字节。第二，与 Java 语言一起提供的 GUI 库产生的应用程序通常看起来与其本机同类应用程序不同。因此，无论您的应用程序多么健壮或稳定，与本机应用程序相比，它都显得非常笨拙。

　　用于 Java 的 GNU 编译器

　　让我们从内存占用问题开始。Java 应用程序要使用额外的内存，因为运行 Java 字节码时，虚拟机必须完成许多“工作”。在当今高级编译器中，编译即时(just-in-time)发生并且编译器必须对这一信息立即(on-the-fly)进行高速缓存以供以后使用。当然，现在内存是便宜，但是当有几个 Java 应用程序同时在一台机器上运行时，即使是大机器也可能由于持续的内存页面调度而放慢速度。进入用于 Java 的 GNU 编译器(GCJ)。GCJ 获得 Java 源代码或字节码，然后将它们编译成本机机器代码。然后，可以将来自几个 Java 类的机器代码链接在一起成为单个本机应用程序。

　　标准窗口构件工具箱

　　GCJ 尚不支持 AWT 或 Swing。因此，我们现在将如何建立本机编译的 GUI 应用程序呢?进入标准窗口构件工具箱(SWT)。这一 API 是开放源码 Eclipse 工具平台的一部分。为了避免引起 Swing 与 SWT 的对抗，让我说明一些 SWT 的优势。

　　SWT 试图弥补 AWT 和 Swing 的缺点。使用 AWT，我们将受到“最小公分母”限制：仅支持存在于所有平台上的窗口构件。因为 Motif 没有提供本机树型窗口构件而 Windows 提供了该功能，AWT 就没有包含树型窗口构件。

　　Swing 走向了另一个极端。虽然带有一个很出色的 API 进行优雅地设计，Swing 还是自己实现窗口构件。因此 Swing 不依赖于操作系统提供窗口构件。无论本机是否支持，这都为 Swing 提供了不可思议的灵活性。但是，因为 Swing 自己绘制这些窗口构件，所以最终的外观看起来与本机应用程序有明显的不同。

　　SWT 试图弥合这两个 GUI 工具箱之间的差距。它的行军命令是：“如果有本机窗口构件就使用它。如果没有，就模拟它。”前面提到的树型窗口构件就是这样一个示例。因为 Windows 支持本机树型窗口构件，所以在 Windows 上运行时，SWT 就使用它。但是，Motif 不支持树型窗口构件，因此 SWT 在 Motif 下运行时绘制其自己的窗口构件版本。使用 SWT，结果应用程序看起来与其本机的同类应用程序很相似，因为尽可能地使用了本机窗口构件。