在2000年代初期的计算机上 ， Swing接口也是出了名的滞后 。 NetBeans在我的iMac 233MHz上根本没法用 。 但它能在我父亲的G4 400MHz上使用 ， 虽然使用感极差 。
在当时 ， 用Java构建GUI需要对摩尔定律（即集成电路上可以容纳的晶体管数目在大约每经过18个月便会增加一倍 。 摩尔定律是内行人摩尔的经验之谈 ， 并非自然科学定律 ， 它一定程度揭示了信息技术进步的速度）有极大的信心 。 它现在非常慢 ， 但可能再发展几年速度会有很大提升 。
2002年 ， 我惊喜地发现了Eclipse和SWT——一种似乎可以解决性能问题的Java GUI开发替代方案 。 Eclipse使用（并且仍然使用）SWT ， 标准小部件工具包 ， 一个新的“重量级”Java UI工具包 。 Eclipse（使用SWT构建）明显比NetBeans（使用Swing构建）响应速度更快 ， 因此从表面上看 ， Eclipse似乎更胜一筹 。
SWT不需要绘制自己的小部件 ， 而只是为平台原生小部件提供绑定 ， 所以使用它构建的应用程序感觉更原生 ， 并且响应速度更快 。
然而 ， SWT最后也让我失望了 。 Eclipse虽然比NetBeans更快、响应更快 ， 但使用起来仍然很笨拙 ， 感觉不是很原生 。 Swing虽然速度较慢 ， 但每个版本都在进行改进 。 我粗略统计了根据关于AWT和Swing的书籍、论坛和博客文章的数量 ， 估计Swing社区比SWT的社区群体大得多 。 Swing/AWT曾经是（现在仍然是）唯一包含在Java中的工具包 ， 你可以构建一个完整的GUI应用程序 ， 而不需要任何第三方依赖项 ， Java运行时环境大不相同 。
尽管我还没有在实际项目中使用过SWT ， 但它的存在让我感到欣慰 。 这些年出现了一些不支持Swing的替代JVM2 ， 并且一直是在此类平台上编写GUI应用程序的一种快速方法 。
据我所知 ， 在2000年初的AWT、Swing和SWT是用于跨平台JavaG UI开发的唯一选择 。 而Java FX直到2007年才出现 。
Java Cocoa Apps
大约在那个时候 ， Apple公开宣布他们将采用Java作为Mac OS X上的一等公民 。 Java将预装在 OS X中 ， 并且赋予Swing一个Native Mac主题 ， 让它们的外观和使用感觉就像一个原生应用程序 。 这意味着你可以将Java应用程序交付给Mac用户 ， 而且可以保证它能够运行 。
他们还提供了将Java应用程序捆绑为原生OS X .app的工具 ， 让你可以将Java应用程序作为一个真正的原生应用程序发布 。 如果你足够严格地遵循Mac用户界面指南 ， 用户甚至不会意识到这些应用程序是用Java编写的 。
不幸的是 ， 大多数Swing应用程序的开发人员没有遵循Mac UI指南 ， 因此用户在使用Java应用程序时仍然会觉得有些东西“不对劲” 。 比如 ， 在应用程序中 ， 菜单项可能出现错误的加速键 ， 或者完全缺少标准菜单 。 事实上 ， 要让Swing UI在Mac上感觉完全原生 ， 需要做很多工作 。
与原生Mac UI工具包Cocoa不同 ， Cocoa提供了一个完全原生的应用程序外壳 ， 并以菜单作为起点 ， Swing应用程序从零开始 。 你必须从头开始创建自己的窗口和菜单 ， 除非你使用的是框架——而且我还从来没有见过一个Java框架可以提供完全原生的Mac应用程序体验 。
但是 ， Apple又为Cocoa提供了Java绑定 ， 这样Java应用程序不仅仅是看起来像一个原生应用程序 ， 它实际上就是一个原生应用程序 。 在这种情况下 ， 你在Xcode中创建一个新的Cocoa项目 ， 并选择Java作为项目的语言 ， 然后它会提供本机应用程序外壳作为起点 。 当你按下“构建”时 ， 它会生成一个完全原生的应用程序 ， 你可以将它发送给你的用户 。
我用这个Cocoa bridge写了一些示例应用程序 ， 并且非常完善 。 但是由于这类应用仅限于Mac ， 所以被Java社区中的WORA狂热者所淘汰 ， 加上“原生”mac开发社区对使用Java并不感兴趣 ， 留下的文档很少 。 如果你想使用Cocoa-Java桥接器 ， 必须熟练地将Objective-C代码示例转换为它们的Java等价物 。 这很麻烦 ， 所以可想而知 ， Apple仅在几年后（2005年）就退出了Cocoa-Java桥 。 再然后 ， Apple对Java失去了兴趣 。 要是你对用Java编写Cocoa应用程序感兴趣 ， 可以去了解一下Rococoa项目 。