Swing的历史

　　要了解Swing，首先必须了解AWT，AWT是Swing的基础。
　　　　的发展速度超出了人们的想象， API中最可视的部分——API突然成为了人们关注的焦点。遗憾的是，原来的AWT不能满足发展的需要。
　　　　原来的AWT不是为许多开发人员使用的、功能强大的用户界面(UI)工具包而设计的，其设计目的是支持开发小应用程序中的简单用户界面。例如，原来的AWT缺少许多面向对象UI工具包中所能见到的特性，例如，剪贴板、打印支持和键盘导航等特性在AWT中都不存在。原来的AWT甚至不包括弹出式菜单或滚动窗格等基本特性，而弹出式菜单和滚动窗格是开发现代用户界面的两个基本元素。
　　　　此外，AWT的下层构件还有严重的缺陷。人们使AWT适应基于继承的、具有很大伸缩性的事件模型。甚至更糟，基于对等组件(peer)的体系结构也被用于AWT，该体系结构注定要成为AWT的致命弱点。
　　　　为了尽快推向市场和保持本地的界面样式，于是产生了基于对等组件的体系结构，而该体系结构注定是要失败的。对等组件是完成薄弱的AWT对象所委托任务的本地用户界面组件。对等组件负责完成所有的具体工作，包括绘制自己、对事件做出反应等，这使得AWT组件除了在适当的时间与其对等组件交互外无事可做。由于AWT类中是较复杂的本地对等组件的外壳，所以，AWT的早期开发人员能在最快的时间(原来的AWT是在不足六个星期的时间内开发出来的。)内创建组件。例如，java.awt.Panel类只包含十二行代码。
　　　　另外，对等组件的设计也有严重的缺点。首先，在大多数平台上，对等组件都是在本地窗口中绘制的。每个组件一个本地窗口实在不能得到高性能，为此，含有大量AWT组件的小应用程序付出了很高的性能代价。
　　　　把不同平台上的本地对等组件硬塞进Java框架中也是一个问题，使这些AWT组件跨平台的表现一致是完全不可能的。结果，不但没有实现急需的新组件，而且开发时间都浪费在修补对等组件的错误上和不兼容问题上了。
　　　　更糟的是，AWT有很高的错误发生率。于是，第三方开始提供他们自己的工具包，这些工具包提供了更可靠的下层构件并提供了比AWT更多的功能。这些工具包之一是Netscape的Interner基础类(IFC)，IFC是一组建立在NEXTSTEP中的用户界面工具包概念基础上的一组轻量类。IFC组件不是对等的，在许多方面胜过了AWT组件。IFC还吸引了更多的开发人员加盟。
　　　　由于认识到Java领域很可能在标准用户界面工具包问题上出现分裂局面，Javasoft和Netscape达成了一个交易，共同实现Java基础类(Apple公司和IBM公司也参加了JFC的开发)。Netscape开发人员与Swing工程师一起合作，以便把大部分的IFC的功能嵌入到Swing组件中。
　　　　起初打算让Swing类似于Netscape的IFC。然而，随着时间的推移。在增加了插入式界面样式等特性并修改了设计之后，Swing大大地偏离了它原来的目标。随着Swing1.1版本的推出，虽然大量的IFC技术仍然嵌在Swing中，但是，Swing与IFC相似的部分已大部分消失了。今天，在一个功能全面的用户界面工具包中，Swing提供了AWT和IFC中最优秀的成份。
　　

【责编:admin】

--------------------next---------------------