主题：【文摘】SWT……内幕？ -- upson
家园 【文摘】SWT……内幕？ 老文章了，今天突然又找到了，放到河里来。
http://www.javaresearch.org/article/12405.htm
SWT……内幕？
FooSleeper 翻译
原文：
http://groups.yahoo.com/group/straight_talking_java/
http://groups.yahoo.com/group/straight_talking_java/messages/24236
翻译整理：FooSleeper
最后修改：2004-03-03
译注：本文来自[email protected]讨论组，已经是一年多前的文章。Alan Williamson是Java Developers Journal的编辑，下文来自他在IBM的一个消息来源。SWT和Swing的论争我见过不少，Netbeans和Eclipse的也同样多。译者翻译此文并不是要激起什么争执，也不是支持哪一方（虽然我的确是站在SWT一边的），更不是要攻击Amy。我最重要的理由是，这是一篇有趣的文章。里面有内幕、线人、公司政治、垄断巨头、美女、商界风云……足够拍一出电影。有趣，这就够了。不过此文反映了IBM对Swing的看法和SWT的由来，还是有一点营养的。
关键词(Tags): #SWT，家园 无聊的老文章 ibm 只所以另外搞swt，并不是因为swt多么nb，或者swing多么滥，最主要还是出于自己的市场利益考虑。ibm做东西，一贯的原则是必须他做主导，而且不能和第三方兼容，以免影响他的整体利益。
随便说一下
1. swt没有任何性能优势，主要性能优势应该是在早期，大概是02，03年左右，那时候sun还没对desktop投入太多的时候。
我们也曾经做过一些相关测试，证明swt确实性能一般。 ibm自己后来都说swt的优势主要在于native的 外观。
2. swing现在也完全可以做出swt的外观效果，可以实现完全native外观效果，有人就用swing完成了一个fake的eclipse，而swt则无法创建swing那样灵活定制的外观效果。 用swing做东西，看你的能力，可以做的非常炫，而swt就那样了。
另外再考虑java 2d 和3d的东西， swt支持还是比较弱的
3. swing目前的第三方组件，支持工具，远远超过swt。而swt现在的主要优势还是基于eclipse平台上做一些扩展的工具开发。
4. 2块我都用来做过完整的项目，最后的结论是，如果是为了项目考虑，swing的选择可能还是更加合理些。尤其是netbean上做开发的话，不会感觉到和visual studio有什么本质的区别。如果是开发工具类的应用， swt才会是我的首选。其实java6已经很不错了，我做出来的东西，客户根本就不相信是pure java做的，呵呵。
5. swt 另外一个主要问题是没有一个能表现复杂布局，又简单使用的layout，而 swing已经解决了这个问题，所以后来除非是做eclipse的插件扩展，我基本不会选择swt， 要简单就干脆用python了。
swing整个框架非常复杂，但是学通了以后很来劲，里面很受smalltalk和dp影响，化几个月时间下来，整个人的层次都有提高。 而swt 更象是微软的东西，结构相对比较简单，有些方面还真不好说，wicket项目当年曾经向swt学习，使用它那种风格，最后发现问题多多，现在又退回去了，搞的我晕菜。而且swt因为缺少一个重量级别的ui设计工具，在易用性上始终达不到他期盼的高度。
以上言论基于06年下半年前我的认识。现在情况不清楚。不过我觉得这类讨论比较detail，又容易有争议，不适合在cchere发吧。现在真无聊，发帖子打法时间。
- 复 无聊的老文章
家园 恩,大多观点赞同 不过有一点,IBM搞swt并非完全出于市场因素,当时的swing确实有一些很难解决的问题,比如它的事件机制.swing和swt的区别本质上就是原生控件与自己绘制控件的区别,这种争论由来已久,从smalltalk开始就有了.只是思路的不同而已.
原生控件就是将主机窗口系统实现的控件诸如按钮,列表框之类的API薄薄封装一下,统一一下,供宿主语言调用,其跨平台的能力,不过就是API级别,说到底,那些控件本来就是由主机窗口系统来实现绘制的,譬如在windows上,就是微软的代码在绘制,而不是swt的,在linux/gtk+ 上则是gtk+在绘制..这样当然就是原生的look and feel了,但是问题是要统一不同风格不同窗口系统的API绝非易事,灵活性也极受限制. 而Swing这样的思路很符合sun的审美哲学,那就是什么都自己来:) 理论上说GUI程序设计,只要你能控制每个像素点的绘制（setpixel()/getpixel())，那么谁都可以实现一个控件系统，swing就是这样的思路，因此当Java2D提供了比较高级的像素绘制能力后，swing就在此基础上得以用“纯Java”实现。。。好处是非常灵活，用swing理论上可以做出任何匪夷所思的外观效果，如果精于计算机图形学，做出比vista/os x 更炫目的东东，我绝对会觉得理所当然。。对你的自由完全没有任何限制。只是这样一来，什么都是自己绘制，自然就不太可能直接获得原生的look and feel了，只能模拟。毕竟，windows 原生应用程序之所以能给你同样的“windows”味道，很大程度上是因为它们用到的大多数公共控件实际都是底层的同一套windows的代码在控制。。。swing这种思路就
完全不一样，它自己绘制。这只是思路的不同，跟是不是Java毫无关系，你把C语言写的gtk+应用移植到windows上去，也会面临同样的问题。
至于孰优孰劣，这个问题仁者见仁智者见智，我就不多废话了
只是swing会给大家造成一些错觉，觉得它太丑陋什么的，这个其实不是事实，它只是一套很简单通用的规范而已，没什么限制，用它来写东西，美，丑，性能都在个人能力。。。
另外，我不太喜欢阴谋论 ：）
关键词(Tags): #java swt swing gui，- 复 恩,大多观点赞同
家园 其实就是市场问题 不过有一点,IBM搞swt并非完全出于市场因素,当时的swing确实有一些很难解决的问题,比如它的事件机制.swing和swt的区别本质上就是原生控件与自己绘制控件的区别,这种争论由来已久,从smalltalk开始就有了.只是思路的不同而已.swing当时确实有缺陷，但是这个缺陷并非不可修订，至少从理论上来说，jdk的规范只限制了接口，ibm自己的jdk实现完全可以从底层解决事件问题。而实际上，当年我用oracle和ibm的jdk跑swing应用就是有差别的，oralce某个版本的jdk，一跑某个应用就死机，这说明底层的实现思路是有差异的。而现在的jvm，swing的事件处理接口并没有变化，但是问题已经基本解决了。
ibm从一开始就希望自己能控制java，所以他的websphere只能在他的jdk上跑，这是很bt的事情。
- 复 无聊的老文章
家园 发吧。争论不要紧，有理有据的讨论尤其欢迎。 只要不是意气用事，不会导致跑题吵架的，争论就会对大家都有好处。
- 复 无聊的老文章
家园 请问老兄对Python，ruby这样的动态语言怎么看 我对Python比较熟悉，对Ruby不了解。您对这两种动态语言怎么看？
家园 搞核物理的也需要学这些时髦的东西吗？ 真是难以置信。
家园 嗯，两种我算都知道点皮毛吧 一直都用来做些辅助的小东西。
动态语言相对于静态语言来说，他的优势在于精简和语法上的一些灵活的特殊结构。某位如果有幸维护俺写过的某段so 长的代码的人就会看到俺在注释里面高呼叫，为啥不是python，因为用python做也就几句话完了。但是这也带来一个副作用，就是不够规范，不容易象java那样大规模的协同开发。举个例子，在java 里面，架构搭建好以后，一个大牛和菜鸟写出来的代码不会有太多本质的差别。这就是java语言可以大规模工业化的先天优势(这点c#，c++都有比较大的差距）。
而当初我学习ruby quiz的时候，则发现一个问题，可以有几十种实现，代码风格也千奇古怪的，从所谓一句话的golf风格到死硬的java风格都有，这样易读性和可维护性会是个大问题，特别是大项目和考虑到普遍新手的情况下，也就是说动态语言开发效率的提高，在某些情况下，是以牺牲某些后期的成本为代价的。而现行ide工具的发展，已经可以部分弥补静态语言在编写效率上不足，而动态语言这块，一直缺少优秀的ide支持，打了不少折扣。这一块python相对还好一些，因为语法够简单，又以缩进的方式强制规范了代码。btw， 以我的经验，对于团队开发，代码规范化远远比代码技巧更重要。
python和ruby则是动态语言里面的两个极端。
python足够简单，基本上翻一翻书上手就会，他也不是纯oo的东西，从入门的角度考虑，更容易为人接受，这也是python生命力所在，另外从发展历史看，python相对来说更加成熟，很多问题都已经有了相当成熟的解决方案。python很适合用来编制一些小工具和辅助软件，这样即充分发挥了脚本语言开发效率的优势，又不会产生太多的维护问题。而对于企业级别的应用，python目前在某些方面也有比较成熟的平台可以去推动，比如zope，但是整体来说，因为专业程度比较高，不会是太主流的。而最近受ror刺激，随后虽然也出了些东西，但是缺少天才程序员的推动，没什么大的反响。一句话吧，就是通用的框架级别的东西不够份量，吸引不到太多的眼球，注定只能在某些特殊领域才能发光。
而相对来说ruby就复杂很多，实际我认为从语法上看，ruby的复杂程度要超过java和c#。 ruby的作者本身开发ruby的原因就是因为python太简单，不够pure oo， 所以从头实现了一个相当复杂的脚本语言。ruby充分吸收了python的语法动态方面的特点，又加入一些很好玩的特性，比如 closure这样的东西和某些oo方面的高级特性。但是真正把ruby推到目前这种火热状态下的原因是ror。长期以来java阵营一直缺少一个高效易用的total 方式的企业应用框架，而ms的。net虽然是一个相对易学和相对高效率的开发平台，但是因为封闭性，一直为广大精英阶层和unix阵营所不耻。 ror的成功在于从框架级别去封装应用的复杂性，再充分利用ruby语言动态简洁的特性，就象一颗原子弹空投进入企业应用市场（这块可占了整个软件市场的80%），降低了企业应用开发的门槛，把所有的大傻都振了一边，然后这才有人反应过来，原来非ms的解决方案，也可以做的这么简单高效。这种震撼的2面，一边是吸引了大量的人投入ruby的学习过程，另外一边是java阵营本身开始进行反思，agile迅速成为主流。
但是就我看来，因为ruby语言本身的复杂程度和学习曲线，考虑到可以预计的很长一段时间，软件业仍然无法解决人力资源短缺的问题，这2个因素直接决定了除ror这样良好封装的框架为核心的企业应用以外，短期内ruby很难有更多的机会成为主流的开发语言。我曾经跟某人说过，如果java学不好，就更不用说ruby了，因为更复杂。除非有更多专业性质的成熟框架出现，全面的降低应用开发的门槛。企业市场，相信很长时间内，aigle后的java和。net还会主流很长一段时间。当然借助ror的热风，如果能够吸引到足够多的java 精英转投ruby，未来ruby提早成为主流也为可知。对于精英来说，复杂总是更有趣的东西，所以这个角度看， ruby会更好一点。
ror并不是ruby的成功，而是一种解决问题的思路的成功， 我在某个项目按ror的一些思路和结合java5本身一些特性封装完成的一个框架，在开发效率和易用性方面同样不输给ror（前提是准对当前项目而言）。而java阵营也存在大量的类似开源方案。未来，竞争还会更加复杂。换句话说，如果python社区抢在ror之前推出一个同样级别的应用开发框架， 现在amazon上最热卖的肯定是python。
另外，在没有得到好的商业支持，实现ide级别的refactor ，代码profile等功能之前，动态语言很难大规模进行开发，尤其是大中型项目，很长一段时间内，动态语言还不会成为主流，只会在特点场合适用。动态语言的真正大规模应用，我可能更看好的是一种变通，即groovy（我更喜欢这种c like风格的脚本语言）， jruby这样能整合传统静态语言和动态语言的方式出现，也就是依赖vm的脚本语言。ms也在做同样的努力， jython的原作者早已经完成了。net版本的python，另外还有若干个可以跑在vm上有趣语言。
还可以发现的一个趋势是传统静态语言的大量动态化特性的引入，或者未来，这个分界会越来越模糊。
我已经脱离开发一线一年多了，这一年可能有大量的新东西出来，以前有个上海人写过一个judo的脚本语言，号称第一种4g 的脚本语言，刚出来也很吸引眼球，归根于商业和应用上缺乏操作，现在已经很少人知道这东西了。所以趋势，还是很难说。