AWT-Swing-SWT

   SWT与Sun的AWT/Swing源自于两种完全不同的设计思想，因此也走上了截然不同的发展道路。三者各有所长，又各有所短。

   众所周知，每种图形界面平台都有自己与众不同的现实风格，Windows是蓝底白字的标题栏和银灰色的背景，Linux是铁灰色的背景，MacOS X则是彩色的水晶图标和白色的背景。

   AWT(Abstract Widget Toolkit)是由Sun提出的最早的GUI技术，它采用了“交集”的办法来解决上述问题，即只支持每个图形系统都有的，最常用的那些控件和显示风格，这样做的好处是AWT中每个控件都可以在本地系统中找到它所对应的，就像本地程序一样利用图形底层的消息处理机制来处理界面操作消息，对用户操作的反应速度快，其缺点就是所支持的控件实在是太少，使得页面单调难看。

   Swing是Sun公司设计的一套图形工具箱，它的目标是打造一套跨平台的图形界面工具。在SWT之前，Java在桌面程序的开发领域一直是举步维艰，这在很大程度上是由于Sun公司对图形界面程序的设计理念所造成的。

   然而Sun却希望将这些风格调和在一起，从最早的AWT到后来的Swing，Sun一直坚持着“界面跨平台”的理念，图形界面程序无论是在那种平台下运行，都要保持不变的风格。用户可以通过在Swing所提供的现实风格中选择他们所喜欢的类型而设置程序的风格。Sun希望，不论用户是在哪种系统中使用图形界面，都可以选择他们所喜欢和熟悉的同一种界面风格，从而达到无缝地在平台间切换的效果。在Swing中，这种风格被称作“LookAndFeel”(L&F)。

   这种想法的初衷是从用户的角度出发，却给图形工具箱的开发带来了极大的压力，在每个平台上界面现实风格都要一致，就意味着，Swing不能直接使用操作系统提供的图形现实功能，而只能“模拟”它们，换句话说：Swing必须自己画出和目标操作系统风格相似的界面。

   Swing采用了使模型和现实分离的方法，控件本身不包含任何和绘制图形相关的代码，而是将绘图代码分分离到另外的类---UI类中。UI类的结构和Swing控件的类型结构基本上是一一对应的，比如JButton类型对应的UI类是ButtonUI，而JTextBox对应的UI类则是TextUI，Swing将这些UI类声明为抽象类，并要求每种L&F都要实现自己的UI类型，在其中添加具体负责绘制控件的图形代码。



  控件的绘制 过程是由Swing中被称为UI管理器的模块控制的，当程序接到绘图请求时，会将这这一请求发给UI管理器，管理器在确定当前使用的L&F类型之后，会根据需要绘图的控件类型获得对应的控件UI类型，然后使用这个UI对控件进行重绘。如果程序员需要改变现实风格，只需要在管理器上调用setLookAndFeel方法重设显示风格，这样下一次绘图时，UI管理器就会使用新的L&F了。

Swing的设计思想精巧，有着不可取代的优势，比如说使用Swing开发者可以自己定义控件的绘制过程，甚至画出他们自己设计的控件，对控件的操作全部使用MVC的结构使得编程的工作简单而又高效。然而它还是存在着一些不足例如和本地程序使用的控件相比，画出来的控件在图形效果，如3D效果等方面还是处于劣势。在性能上也不如使用本地操作系统API创建的本地控件相比。

      一直以来Java语言在企业级程序开发领域占据着主导地位，但是在编写桌面程序方面却不尽人意，人们甚至已经有了“Java写的GUI程序速度缓慢而且界面不美观”的观念。在Eclipse推出的时候，它的精美界面让人耳目一新，这都要归功于Eclipse的底层图形技术---SWT。
   SWT(Standard Widget Toolkit)，是一种使用Java开发的GUI程序技术，于Sun的AWT和Swing不同，SWT是Eclipse开发人员自行建造的，无论是在界面的美观程度上还是在性能上，都远远超出了前两者。
   SWT吸取了前两者的有udian，综合而成一种技术，SWT吸取各个图形平台的经验，自己定义了一个控件集合，然后针对某个目标平台进行判断，目标平台上有的控件，SWT会直接使用，以达到快速处理和本地化的显示效果，目标平台上没有的控件，SWT会采用Swing的方法进行绘制。
   谈论这三者的优劣，本身没有太大的意义，因为设计目的从一开始就不一样，也有着不同的目标客户，最终的选择，还依赖于程序设计的目的和客户的需求。