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必将不断呈现出令人乐观的效果。
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货