swt 内幕？

译注： 本文来自straight_talking_java at yahoogroups.com 讨论组，已经是一年多前的文章。Alan Williamson 是Java Developers Journal 的编辑，下文来自他在IBM 的一个消息来源。SWT 和Swing 的论争我见过不少，Netbeans 和Eclipse 的也同样多。译者翻译此文并不是要激起什么争执，也不 是支持哪一方（虽然我的确是站在SWT 一边的），更不是要攻击Amy。我最重要的理由是，这是 一篇有趣的文章。里面有内幕、线人、公司政治、垄断巨头、美女、商界风云......足够拍一出电影。 有趣，这就够了。不过此文反映了IBM 对Swing 的看法和SWT 的由来，还是有一点营养的。 From: Alan Williamson Date: Wed Nov 6, 2002 10:31 am Reply-To: To: Subject: SWT ... the scoop?（SWT......内幕？） 好了这就来......阅读......消化......再阅读......再消化...... 谢谢你的回复。我很乐意给你提供Swing 和SWT 背后的一些信息，既然你还把我当作你秘密的“IBM 内幕线人”。 要想弄清楚为什么一切都被弄得如此混乱，要从几年前只存在AWT 的时候说起。SUN 当时已经建立了一套基本的可移植控件类，这些类映射到不同操作系统上的原生窗口组件（native widget），显然下一步应该继续增强这套模型，除了初始的CUA 92 组件（文字、按钮等等），再继 续加上表格、树、记事本、滑块等等......当时的AWT 还满是漏洞，远不能称为可靠，还需要SUN 的coder 们去修补。SUN 的developer 们如Graham 和Otto 总是习惯于公开把他们的bug 归咎为操 作系统的差异，比如“Windows 和OS/2 的焦点次序不同”或者“在......之间Ctrl-X 的行为不一样”，以 及其他苍白的托辞，好让批评的火力从SUN 太早释出代码这个问题的真相上移开。然后Amy Fowler 来到了SUN。不是我大男子主义，Amy 是个聪明的美女，大多数呆头呆脑只懂技术的开发人员都 要被她捏在手里。Amy 来自一家Smalltalk 公司，叫做Objectshare，在那里她负责搞UI 类库。跟Java 相比Smalltalk 的历史有些悲惨，曾几何时有3 家庞大的Smalltalk 公司??IBM、Parc-Place 和Digitalk。 在90 年代初期3 家公司的市场份额大致相等，生活是美好的。Parc-Place 采用仿窗口部件（emulated widgets）的设计（即Swing 的设计），IBM 和Digitalk 则采用原生窗口部件（native widgets）。后来 IBM 压倒了另外两家，因此他们打算合并成一家，假设叫做Parc-Place Digitalk。随后当他们试图将 他们的产品融合到一个叫做Jigsaw 的计划中时爆发了一场大战，计划由于政治原因失败了（开发人 员实际上已经能让它运转起来），就因为原生和仿造两派的死战。Amy 赢得了精神上的胜利，不过 在IBM 我们赢得了他们所有的生意，因为这两家公司在一整年里除了吵架什么都没做。当尘埃落 定之后PPD（Parc-Place Digitalk 当时已改名为Objectshare，跟Windscale 改名为Sellafield 的原因相 同??让人们淡忘之前发生的灾难）的股票价格从60 美元掉到了低于1 美元1 股。他们因为伪报收 入被NASDAQ 摘牌，从此消失。此时SUN 正走上与PPD 类似的技术方向，于是PDD 的技术人员 都把他们的简历投到了SUN。Amy 被雇佣了，她承诺通过轻量级方案解决所有窗口组件的问题， 因此SUN 管理层让她当了GUI 开发部门的头头。她是拿着“这里原来的人都搞砸了，我是来解决的” 的钥匙进来的。随后Amy 雇佣了所有她过去在Parc-Place 的旧朋友，让他们来开发Swing。 显然 Swing 应该做的是仅仅成为一个绘制框架，给那些希望创建地图软件或者绘图软件的人们使用，无 论如何，应该围绕AWT 类库来建造它，按钮之类的东西仍然交给AWT 来管。SUN 的人比如Philip 和Mark 已经让AWT 能够处理表格、树和记事本（notebook，？），所以Swing 的方向应该说很明 显了。但那些毁了PDD 的人不干，他们非要把一切都弄成轻量级的。由于SUN 管理层的无知，再 加上Amy 无情的政治手段，造成了我们今天所见的混乱局面。Amy 还使SUN 相信Swing 是作为 Mozilla 项目的一部分与Netscape 联合开发的，事实上这只是她的宣传伎俩。 在IBM，我们从第一天起就憎恶Swing。庞大、满是错误，而且难看至极。原先我们的工具如VisualAge for Java 都是用Smalltalk（用的是原生窗口组件）写的，所以当我们将这些工具向Java 代码库迁移 时，我们需要一套窗口组件。IBM 这边的开发人员都是原来搞Smalltalk 的那一批人，我们对管理 层要求用Swing 来构建WebSphere Studio 工具都非常不情愿。Swing 是个可怕的充满缺陷的怪兽。 在WebSphere Studio 最初的预览中，当与Microsoft Visual Studio 作对比演示的时候，我们所有的客 户都讨厌它，就因为它的外观，而不管它的功能有多强。大多数消费者都不会买一辆让人觉得难看 的车，哪怕这车有一台出色的引擎。因此我们开始了一个项目，是把我们的Smalltalk 原生窗口组件 移植到Java 上去。这个项目是加拿大的Object Technology International 小组做的。这个项目获得了 成功，被运用在在我们发布的VisualAge Micro Edition 产品中，VisualAge Micro Edition 后来成为 J2ME 开发方面一个非常成功的IDE。但是OTI 的人发现，Swing 在读取Windows 事件方面有极严 重的缺陷，我们甚至无法进行SWT（S 开始是Simple 的缩写，不过后来变成了Standard 的 缩写） 和Swing 间的互操作。他们在读事件队列的时候用了一种可能留下内存漏洞的方式，所以我们不得 不采用我们自己的查询Windows 事件队列的循环，以纠 正这个错误。我们试了一次又一次让SUN 修复这个错误，但Amy 就是听不进去，所以我们才决定SWT 和AWT/Swing 不能共存。我们甚至 在SWT 中定义了自己的Point 和Rectangle 类。整个工具包对AWT 或Swing 都没有任何依赖。我 们把这个工具包放到了Eclipse 中，这是一个工具平台，它的总体设计目标就是要战胜Micrsoft 和 Visual Studio。Eclipse 是开源的，所以任何人都可以在上面构建自己的东西，我们已经有像 TogetherSoft 和Rational 这样的公司移植到了上面。我们的竞争者是Microsoft，所以我们所有努力 和注意力都是从正面针对Microsoft。 不管怎么说SUN 对此非常不满。他们的Netbeans 跟Eclipse 做的是相同的事，因此他们向IBM 高 层抱怨。他们认为是要将你绑到Windows 上，这纯粹是胡说，因为SWT 能通过GTK 在Mac/Linux 上运行，以及一大堆嵌入式平台。他们拒绝让Eclipse 获得Java 认证，因为里面有原生代码，所以 Eclipse 产品必须很小心地使用单词“Java”这个SUN 的商标。Eclipse 甚至不能把自己称为一个Java IDE，SUN 已经威胁过要采取法律行动来制止IBM 在任何时候把Eclipse 称作一个Java IDE。结果 之一就是IBM 在Eclipse 上创建的GUI 设计工具，允许你构建Swing/AWT GUI，却不让你往里面 拖放SWT 窗口控件。将SWT 从Eclipse 中分离出来是完全可能的，只需要把DLL 抠出来放到路径 中，并使用窗口组件工具包来给你的银行或者保险或者其他什么应用程序开发GUI。再次说明，我 们无法更进一步，因为SUN 把我们的双手绑上了。虽然作为Eclipse 开放源码协议的一部分，CPL 允许我们提供这样的解决方案，但SUN 已经很清楚地表明他们不希望我们这样做。对于用户社区 来说，无论IBM 和SUN 的最终动机是什么，我发现有一点总是很有趣：喜爱Swing 的人总会说“一 旦你花上几年时间去掌握它，你就能正确地使用它”，这基本上是他们在试图证明和维护他们辛苦 得来的用途有限的专门技术；而SWT 的拥护者们说的是“哇，这真快，这跟原生的一样，还可以用 XP 皮肤......它还又轻又小”。有一句话是我喜欢的，我们的一个用户说，Swing 就像Java 决定不通 过操作系统来实现原生的IO，而是通过磁头马达 API 自己来读磁盘的扇区。Swing 基本上就是这 样的，它拿着个底层的“paint(Graphics)”方法，自己来绘制所有的窗口组件。