swt和swing，我自己写的。

[djsl6071]

swt是在早期awt失败的基础上ibm做的jni扩展，其基于的，主要还是当时的

awt，也就是java1.1或2的时候的原生组件，而这个基础当时被认为是失败的，ibm的理解是sun应该在这

个"因易用性欠缺而导致失败"的产品上扩展易用性，而sun的Amy认为awt是"无可奈何的不得不忍受的本地

图形接口包装"的产品,跨平台的gui下一步应该开始完全独立的绘图和桌面组件设计。其实二者都认为awt

谈不上失败，因为它不能算是真正的gui，而他们也各自在awt基础上开发成熟而易用的gui。

swt/jface的速度可以视为操作系统次级的，也就是说最快也只能是操作系统的速度(这个有点大言不惭了

，swing的执行速度确实还不如它，尽管比较早期，java swing的每个版本都有一定的提速，这个后面会

提到)，然而，二者的基础awt却是严重影响性能的瓶颈，由于二者同时使用之，便出现了这样有趣的历史

:

早期，借由操作系统实现绘制时，swt速度优于swing，这个优越绝对不是一点点，然而软件开发的复杂程

度，随着组件设计的复杂化和平台间的差异程度更明显的制约作用，呈指数级的扩大，同时，由于swt基

于awt的基础(这个基础的含义不以复用和继承为主，而是说它基于awt的实现方式，在本地图形窗口库中

寻求对等体(peer)的解决方法，它的实现必然被jni和awt"双规"，今后的发展空间，主要靠程序员编写多

平台的支持版本，swt/jface就好像在用本地api写程序，尽管用java的语法包裹着，却不得不时刻小心平

台差异造成的小问题，那些类库被限定在由开发人员提供，有了新的设计思路，想要重写是相当困难的(

涉及jni，也就意味着你还要了解例如c/c++等在本地api上实现的技术－－会了这些，完全可以找一份不

错的windows软件开发工作，同时人们也会想，ibm的开发人员是优秀的，为什么不等到下一个应用了新的

设计的版本中再去使用呢，于是，一切的压力都转嫁给了ibm的开发人员，他们要在复杂多样的操作系统

中找寻桌面窗口组件的共同点和差异，一手练就jni技术，一手紧跟java发展的脉搏，一边再为更先进成

熟的设计理念的应用绞尽脑汁，想到这里，不禁想起一个在ibm中的同学，恩，果然是大牛级的人物啊)。

swing同样使用了awt，却以复用和继承为主，这意味着它同样被限制在了"无可奈何的不得不忍受的本地

图形接口包装"－－awt中，除非世间只有一种操作系统(那时awt一定能得到最大优化，甚至swing没有了

存在的必要)，否则我想这样的牺牲的必然的，灵活之处在于swing是基于此上的纯轻量级设计，以牺牲现

有速度为代价(现有指的是1.3等版本的时候），换取完全的与操作系统无关的自由发展空间，swing就好

比在jvm之上的一张白纸，随你怎么画都可以，一切底层都与你无关，你只要关注java开发业务，涉及的

底层性能问题，交给sun帮你搞定了，当然盲目信任是不可以的，幸好sun也只能基于awt做纯java上的扩

展，随着java不断提速，随着更好更新的设计理念可以直接相对不复杂地被借鉴到swing中去，也随着更"

奢侈"的操作系统，如vista，之上本地程序运行速度的一定程度弱化，swing必将不断呈现出令人乐观的

效果。

[cunsh]

mark

[约翰羊]

学习

[a8322185]

mark

[djsl6071]

觉得写的不好，也很有问题，大家多批评一下，好让我懂一点。

[Yanbin_Q]

写的不错，我也比较看好swt,所以现在在苦练 windows api,力求对操作系统本身多些了解，用depends查看swt.dll文件，可以看到其中导出了许多的windows api函数。

现在似乎是本地程序慢慢优势不明显了，我还只是觉得vc程序发布特别方便，传个可执行文件或者再加些动态库别人就能用了，而不是随手做个小工具也要求别人机器上安装个jvm，也好几兆或十来兆，不小。