Swing的歷史

2019-11-18 11:56:21

字體：大中小

來源：轉載

供稿：網友

　　要了解Swing，首先必須了解AWT，AWT是Swing的基礎。
　　　　java的發展速度超出了人們的想象，Java 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中最優秀的成份。

上一篇：Swing組件

下一篇：Swing簡介