Let's Swing Java

所谓事件就是指发送给GUI系统的消息，该消息通知GUI系统某种事情已经发生，要求GUI系统作出响应。事件根据其来源可以分为以下几种...[Read More]

使用和研究Swing已经很长时间了，随着对swing理解的加深，觉得自己对一般计算机GUI(图形用户界面, Graphical User Interface)系统的领悟也越来越多，甚至开始觉得自己理解了一些GUI系统的本质。曾在新浪的博客上写过一系列文章，试图从原理到实现上讲述 swing体系结构，现在却觉得仍是没能描述清楚，总觉得缺少从一般原理上理解swing架构的感觉。于是觉得应该把平时悟到的关于GUI系统原理的火花 整理出来，也许对更清晰地理解swing有所帮助...[Read More]

最近两天swing_designer的进度是...[Read More]

        这两天swing_designer的进度还算可以，到昨晚为止，已把事件代码编辑功能添加上去了。事件编辑功能是作为属性编辑页的模式添加上去的。由于 不是某个JavaIDE的插件，所以代码编辑器只是个简单的文本编辑框，不具有任何代码辅助功能，也不打算加这些功能，因为这些功能偏离当初设计这个项目 的初衷...[Read More]

         最近一直比较忙，不仅仅是工作上，私人事情也很多，所以swing_designer一直处于缓慢进展中，一直也没有抽出时间来写文章，只把现有的成果继续完善。其中最重要的几个进展是...[Read More]

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%

结论是：
SWT不会消亡，因为有Eclipse的存在，如果想为它开发插件，就必须使用SWT。另外和AWT相似，SWT可以应用到Mobile开发界面上，因为Swing毕竟太大了。
Swing因为Java5和6的推动将席卷Java Desktop市场。

毕竟任何的东西的存在都是合理，存在即合理，合理就不可能消逝。80/20的关系。

对我的话持怀疑态度的人，尤其是Swing的速度可以去看看JavaLobby的这个帖子：
http://www.javalobby.org/java/forums/t78884.html
如果对Swing占有市场率有怀疑的人可以去看看这条新闻：
http://www.clientjava.com/blog/2005/10/18/1129665205787.html

I heard a piece of news from NetBeans community that the GroupLayout is bundled into the JDK build 76. Please search for "Add GroupLayout to core" (bug #6375459 at java.sun.com):

https://mustang.dev.java.net/files/documents/2817/31069/mustang-b76.html

To me, this is really an piece of exciting news. It was finally there! I have downloaded the snapshot binaries and installed it. Compared to Matisse version, some of the API has been changed besides the package name(It is named under javax.swing package). I think at least changes to make use of JDK group layout in both Matisse and JDK.

1. The matisse code generator should be changed to use JDK GroupLayout.
2. GroupLayout should also be back ported to 1.4 and 1.5 so that NetBeans don't have to bundle its own group layout.

Now, NetBeans does not support mustang officially. We have to wait until mustang final release comes out. But anyway, we've got the excited news that it is going to be integrated into mustang.

Finally, it is there!
Cheers.

Java has been prospering since its born, mostly because of its WORA feature. In java, the bottom line is WROA rule should not be broken. Though AWT has kept the rule, it fails due to the wrong implementation strategy: LCD(Lowest Common Demoniator). That is, a component will not be accepted as a AWT component if it does not exist on one of the major OS platforms. Due to LCD strategy, AWT can not provide enough rich UI components and functionalities. This led to its final failure.

IMHO, SWT is following the same old road. SWT people may argue that SWT implementation is totally different from that of AWT, that SWT combines native calls using java code and provide platform independent API, that SWT uses emulation as Swing does to provide missing components on specific platform. Yes, SWT make up the component level LCD defects by native stub calls and java emulations. But, how can it compensate the component feature level missing? What if a component has a feature on some platforms while misses this feature on a specific platform. For example, on some platforms icon cannot be placed on a button unless it is toolbar button. What will SWT do? Will it implement the component feature using LCD rule? It is very hard to imagine to emulate this feature by SWT strategy, IMHO.

What's more, because of the blackbox nature of native OS components, it is very hard implement rich functionalities by wrapping native components using java code. This is another place where AWT and SWT failed.

Maybe I am wrong in stating that SWT cannot overcome a component platform specific feature. But I doubt using SWT strategy can solve this problems. If it cannot solve it, it is stepping the road AWT has stepped. It cannot provide as rich component features and functionalities as Swing does. If it can, I think the application developed with SWT must be platform specific, not accordant to WROA.

An opinion backing SWT boasts why should we support multi-platform and be WORA. The answer is why you should choose Java since you don't want to be WROA.

Just my $0.02.

It is said in Hans Muller's blog that Evans Data Corporation has reported that Swing is the dominant GUI Toolkit for Northern American developers.

"Java Swing with 47% use, has surpassed WinForms as the dominant GUI development toolkit, an increase of 27% since fall 2004."

So finally Swing returns, after 8 years of FUD, especially after the emerging of its obvious competitor: SWT.

Let's celebrate the return of the King!

Cheers!