1. Visual Editor (VE) for Eclipse

   开源，免费

   不知道设计人员长不长脑的,打开一个VE编辑器就要开一个javaw进程,每个进程至少20多M,试问一般人能有多少内存?

   这个还不算,编辑的反应速度可以和蜗牛比美,功能简单,块头不小,更新缓慢,1年时间(06-07)还没什么变化。

2. WindowBuilder for Eclipse

   试用期版，收费版，无免费版本

   貌似和VE使用了差不多的技术，起码是都是使用了GEF框架。

   和VE有一样的大毛病，反应速度特别慢，每动一下都要等它重新解释完，气人的是，不能暂停解析，写一句代码都要折磨死人。

   到Designer 6.2.0有个很严重的BUG，不知道后面的修改了没－－保存时默认是重新解析的，只见控件层次树不断的刷新，CPU占用100%，一般要等上10秒才能完成，期间整个Eclipse死掉！

   优点是功能强大，也很全面，但就是解析慢的缺点足以让人无法忍受！

   有时出错后就看不到整个GUI，非常恼火。

   它非不是完全解析代码的，只解析部分代码，一部分是不解析的，如各种model，所以设计时和运行时有较大的差异。

   对GroupLayout支持不错，可以很方便的设置（解析耗时不计算的话）

   对无布局(null)支持也很好，可以看到很多定位线！

  512MB内存经常死掉，然后报溢出？！！

3. Jigloo for Eclipse

   个人版本免费，商业版收费

   它与WindowBuilder各有千秋，功能也相当，丰富性上比WindowBuilder差些，更新也慢些，可能是免费的原因吧。

   特出优点：

   1).完全解析代码，在编辑时基本可以看到运行时的界面，可以正确解析很多自定义的类，模型，如各种renderer..

   2).可以暂停、重新解析，从编辑加载。这个在实际使用时非常好用！因为一般不可能完全拖放好界面后就不动的，经常要反复修改，编辑器的能力毕竟有限，很多问题非手工不能解决。

   这两个特点都是这4个插件中Jigloo唯一有的。

   另外，它的解析能力非常强大，VE,WindowBuilder,NetBeans拿过来的类一般可以编辑。

   体积小巧，总大小不超过3M，却有如此的效果，实在是强悍（VE 不带GEF和EML都有17M，WindowBuilder 26M）

   缺点：

   编辑界面比较难看，左边对齐图标又小又看不清

   选择了一个控件后，不要，按ESC取消时，经常无效，一个很不爽的BUG

   3.9.5版本在拖动改变控件大小时经常会出错，宽度设置成65536（Max Short?）

   不支持JDK1.6的GroupLayout，而是javadesktop的GroupLayout,多少有些不方便，不爽

   有时会出现重复声明变量，一般是layout...

   令人讨厌的GUI Builder属性窗口老关不掉，一定要出现在view里面。这个属性编辑非常不方便，选择不方便。。还有时编辑后不修改代码，非得手工去修改，还好这个比较方便修改。

   GUI编辑区域的背景网络线怎么设置都会出现，密密的看得眼花，真想不明白，在背景（窗体外部的）网络要来有什么用，又不能定位！！？？

4. NetBeans

   免费

   强制保存GUI生成代码，无法手动编辑（只能用外部工具打开源文件修改），非常不爽，因为一点点代码修改都要通过各种向导……

   界面编辑反应非常快，基本不用停顿！！

   对GroupLayout的支持也很好，关键是反应快，可以令工作进行得非常愉快。

   缺点：

   不能直接解析java源文件，不能解析其它工具创建的代码

   界面不能设置风格，编辑（系统风格）与运行（Java风格）天地之别

   属性编辑器非常不友善，找头天还找不到

   控件图标不容易辨认，看起来差不多都一样（狂汗！！）

   补充一句，NetBeans的界面真让人恶心，真不知道是怎么设计的，就算是全部手工写出来的也不能原谅！

   如：窗口通常不留空白，再省也不难省这点吧！？？

另外，现在使用JTable，数据量超过100条的时候，查询出来再绘制成JTable中，需要的时间很长！是不是代码哪里有问题？不知有没有人曾经遇到过？

http://blog.sina.com.cn/u/4b6047bc010006r1

　SWT从实质上说是头疼医头，脚疼医脚，这种本质决定的它的架构不好，当需求增加时，当面临现实的Customization时，当面临各种不同操作系统时，它的缺点就暴露出来了，简单的说：
　　
　　 对Java 界面涉及不深的人往往偏好SWT，对Java界面设计非常熟悉才能真正洞悉Swing的内涵。人们对于SWT的喜爱是同他对SWT的了解深刻度成反比的， Swing恰好相反。对于SWT了解越浅的人，越对他的光鲜外表（主要是Eclipse的表现比较好，但毕竟Eclipse的漂亮程度归公于他的界面设计艺术，实质并不在SWT的高级）。随着开发者对于SWT的深入了解，就会发现越来越多的问题和局限性，了解不深的人，或者从传统C/C++， WinForm以及MFC等东东转过了的人，往往被SWT的表面所迷惑。可以不客气的说SWT是AWT早已抛弃的努力。
　　
　　 SWT凭着它对Windows平台的优化迷惑很多人，又以它的编程简单性忽悠了很多人。其实SWT它在Linux的效率和Mac OS上的错误简直要让人发疯。如果你真的想需要Windows平台的界面，干嘛要用Java? C#岂不是更好？
　　
　　 SWT 一个迷惑人的地方是所谓平台保真(Fidelity)，其实这也造成它不能轻易扩展和Customization的根源，而且，开发者往往喜欢平台保真的界面，而用户却不一定，相当的用户最终喜欢WinAMP等类似可以更换皮肤和LookAndFeel的功能。即使是平台保真度，Java6已经完完全全的实现平台一致性。SWT已经没有优势可言。
　　
　　 SWT的另一个迷惑人的地方就是所谓速度，人们往往认为本地组件就比模拟组件要快，其实不然，由于 Java虚拟机和运行时速度的提高，Java编写的程序已经可以与C的速度相媲美，加上Swing内在有虚拟机内嵌代码和热编译的等功能支持，Java实现的Swing代码已经和操作系统本身的组件没有什么两样了。最近有JavaLobby上论坛贴出了一个名字叫MiGLayout，关于测试GUI界面的 BenchMark，测试的结果是：
　　
　　 Windows平台上Swing的启动速度稍慢于SWT，运行速度几乎一样。
　　 Linux平台上Swing的速度高于SWT，无论是启动速度还是运行速度。GTK2上的速度差别就更大。
　　 MacOS上Swing的速度高于SWT，无论是启动速度还是运行速度。
　　
　　 IBM当时开发Eclipse时，Swing的确不争气，所以才有了SWT的出现，但是如果当时Sun就把Swing打磨成现在这个样子，估计IBM也不会轻易开发SWT，但也多亏SWT的出现，促使Sun将Swing进行改革。
　　
　　 最近一个国外叫EvansData的咨询公司调查的GUI工具结果是：
　　 swing占有率47%，名列第一，WinForm名列第二，SWT不超过8%