引用

谈论 阅读文章
发信人: qyjohn (Sweet Potato -- 丽江，铜鼓岭...),
信区: Java
标 题: 从Oracle收购Sun 公司谈起
发信站: 水木社区 (Tue Apr 21 12:08:16 2009), 站内

http://www.qyjohn.net/

4 月20日，Sun 公司董事会通过决议，同意以每股9.5美元的价格将公司出售给Oracle。虽然还有一些必要的审查和手续，但是两家公司的合并，看起来是不可避免的了。一时间，很多IT领域的朋友众说纷纭，对Sun 公司各种产品和技术的前途提出种种预测。在这里我个人就Sun 公司软件部门的一些产品和技术（包括Solaris操作系统，Java编程语言，MySQL数据库等等）的未来发表一点看法。需要说明的是，虽然我个人在 Sun 公司工作，但是并没有任何机会接触到公司决策层的任何相关资料。因此，在本文中出现的所有观点，仅仅是我个人的观点，而不是我的雇主Sun 公司的观点。

Solaris操作系统

在Oracle与Sun 公司共同发表的新闻稿当中指出：Sun 公司所拥有的Java语言和Solaris操作系统是“根本性的长期战略优势”。Solaris操作系统对于Oracle的重要性，由此可见一斑。

作为一家数据库厂商，Oracle做梦都想要拥有自己的操作系统。在没有自有操作系统的情况下，唯一的选择就是全面支持市面上各种操作系统，根据市场的变化来调整不同操作系统的优先级。2000年之前，Sun 公司正如日中天，在金融、电信、能源等多个关键性领域的装机量排名第一，因此Oracle选择将Solaris作为优先考虑的操作系统。2001年前后，GNU/Linux在服务器端的性能已经相当出色，可以运行在价格低廉的x86处理器上，能够方便地从网络上免费下载到安装文件。更重要的是，大量向往自由的技术人员通过各种渠道分享经验，在网络上很容易找到与GNU/Linux相关的各种文档。与此相反，Solaris需要运行在昂贵的 UltraSparc处理器上（当时x86版本的Solaris 8已经可以免费下载，但是还远远没有达到健壮实用的程度），安装过程烦琐复杂，系统管理员还需要经过Sun 公司的专门培训。随着互联网泡沫的全面破灭，企业对信息系统的性价比提出了越来越高的要求。在这种情况下，Solaris的新增装机量开始下降，无须财务主管审批即可立即部署的GNU/Linux开始占领数据中心。Oracle敏捷地注意到了这个趋势，于2002年推出了名为“坚不可摧的 Linux”（Unbreakable Linux）的客户支持计划，开始向GNU/Linux倾斜。需要注意的是，“坚不可摧的Linux”并不是一个新的GNU/Linux发行版，而是指 Oracle向 Linux用户提供的软件更新以及技术支持等等增值服务。与此同时，Oracle开始加大在操作系统方面的投入，慷慨解囊资助GNU/Linux社区中的多个关键性项目，同时试图构造一个全新的GNU/Linux发行版。由于操作系统的复杂性，Oracle在自有操作系统方面的进展缓慢。由于与IBM 公司的DB2存在正面竞争，尽管Solaris的市场正在萎缩，Oracle依然将Solaris作为优先考虑的操作系统。2006 年，GNU/Linux在数据中心的新增装机量已经超过了50％，Solaris的新增装机量则降低到15％以下。这时候Oracle的首席执行长官 Larry Ellison做了一个聪明绝顶的决定：将Red Hat的图标换成Oracle的图标，将“Red Hat Enterprise Linux”几个单词修改成”Oracle Enterprise Linux”，一举推出了与Red Hat Enterprise Linux完全兼容的Oracle Enterprise Linux，同时推出价格仅有Red Hat一半的客户支持计划。尽管业界对此众说纷纭，Oracle终究是依靠GNU/Linux社区的强大实力摆脱了对Solaris的依赖，同时也过了一把“自有操作系统”的瘾。

2006年4 月，在被问及是否会考虑收购Red Hat的时候，Oracle的总裁Larry Ellison信心满满地说：Oracle不会收购一家随时都有可能被淘汰的公司。尽管如此，Red Hat成功地用市场份额证明了他们比Oracle更懂操作系统。Oracle可以轻易地将Red Hat和Novell等等公司贡献给开放源代码社区的成果拿来使用，却无法拿来这些公司在开放源代码领域的声望，也无法拿来用户对这些卓有贡献的公司的忠诚，

这也许是Oracle收购Sun 的原因之一：Sun 懂得操作系统。在文件系统方面，ZFS是目前为止功能最强大的文件系统；在应用开发方面，DTrace能够轻易从内核层和用户层寻找应用程序的瓶颈；在系统安全方面，Solaris Trusted Extension获得了最为全面的EAL 4+认证（包括LSPP, CAPP, RBAC）；在超级计算方面，目前世界排名第六的德克萨斯超级计算中心（Texas Advanced Computing Center）运行的是Solaris操作系统。（需要说明的是，排名前五的超级计算机运行的都是不同版本的GNU/Linux操作系统。）尽管新增装机量的增长缓慢，但是在世界各地的数据中心里，依然有10％左右的服务器在运行不同版本的Solaris操作系统。通过收购Sun 公司，Oracle可一举获得操作系统领域的核心技术、人才、声望、以及现有的客户。

因此，Oracle不会放弃Solaris操作系统。剩下来的问题，是如何继续Solaris操作系统的开发。Oracle是会继续支持目前的 OpenSolaris项目呢，还是会采用传统的闭源方式？我个人的看法是，Oracle有可能在GPL授权协议（有可能是GPLv3）的框架下重新发布 OpenSolaris项目。OpenSolaris目前最大的问题，是硬件兼容性的问题。在x86/x64平台上，尚有大量的声卡、网卡、显卡以及其他外接设备没有OpenSolaris的驱动程序。类似的问题，GNU/Linux社区已经解决得比较好了。相关的驱动，基本上都是开放源代码的，只是由于 GPL协议和CDDL协议之间互不兼容，使得OpenSolaris社区无法利用GNU/Linux社区的这些成果。我在《回顾：OpenSolaris 2008.11》一文中明确指出：使用GPL授权协议发布OpenSolaris项目，在技术上可以解决OpenSolaris项目所面临的困境，在感情上可以消除GNU/Linux社区的敌意。的确，使用GPL授权协议使得GNU/Linux社区也可以充分利用OpenSolaris项目中诸如ZFS和 DTrace等等亮点，但是从长远来看，恐怕是OpenSolaris项目得到的好处要更多一点。毕竟，对于一位普通的开发人员来说，没有ZFS和 DTrace的GNU/Linux已经足够好用，但是没有声卡网卡驱动的OpenSolaris就不太好用了。

关于开放源代码软件，Larry Ellison有一句名言：“如果开源软件变的足够好了，很简单，我们就把它拿过来用。”现在GNU/Linux在设备驱动方面的优势如此明显，Larry会放过这个机会吗？

Java编程语言

谈起Java编程语言，我们首先要明确Java语言目前有三个分支：Java SE（标准版）、Java EE（企业版）和Java ME（嵌入版）。Java SE是Java EE和Java ME的基础，类似于国家自然科学资金的基础性研究项目，基本上是光花钱不挣钱的。Java EE可以认为是Java语言在企业级解决方案中的应用，大部分做Java的公司，除了Sun 公司之外基本上都是依靠Java EE盈利的。最近几年，Java EE俨然是企业级解决方案的事实标准。以中国的情况为例，2008年40％的企业级应用是基于Java EE的，35％是基于.Net的，另有18％是基于单纯的HTML和JavaScript的。Java ME可以认为是Java语言在嵌入式设备方面的应用，譬如说现在大部分的手机都支持Java ME的某个子集。在2006年之前，厂商每生产一台支持Java ME的手机，要给Sun 公司支付一定的授权费用。2006年11月，Sun 公司启动了名为PhoneME的开放源代码项目，这个收入就变得不是十分可靠了。

在如上三个分支中，Oracle最感兴趣的显然是Java EE。但是在收购Sun 公司之前，Oracle已经收购了这个领域的大牛BEA。以应用服务器（Application Server）为例，在中国2008年BEA的WebLogic的市场份额为27％，仅次于IBM的WebSphere（29％），Oracle自己的应用服务器占7％，而Sun 公司的应用服务器（GlassFish）仅占4％。又以门户服务器（Portal Server）为例，在中国2008年BEA的WebLogic的市场份额为32％，比IBM的WebSphere（31％）还要高一个百分点，Oracle自己的门户服务器占10％，而Sun 公司的门户服务器仅占7％。显而易见，让Oracle暗自动心的不是Sun 公司在这个领域的市场份额，而是Sun 公司作为Java语言的发明者在这个领域领导地位。可以想像，在两家公司合并之后，Oracle必然会将Sun 公司目前的Java EE部门一分为二 －－写标准和申请专利的继续写标准和申请专利，开发应用服务器的则并入原来的WebLogic部门。至于Sun 公司自己的应用服务器GlassFish，至少这个品牌想来是不会再用了。下一代的Java EE参考实现，叫做Oracle WebLogic显然要响亮得多。按照同样的推理，Sun 公司原来叫做Java企业系统（Java Enterprise System, JES）的那套东西，本来占到的市场份额就很小，合并之后跟Oracle现有的中间件产品线发生冲突，也将逐渐退出历史舞台。

Java ME是一个比较难办的问题。随着各种高速无线网络的普及，移动与嵌入领域正在变成下一个金光闪闪的企业级取款机，但是Oracle在这个领域却毫无经验。我个人的观点，是Oracle会让这个部门继续独立运作一段时间，但是会指派一位党委书记（有可能是从外部新招来的）前来参观学习。等这新来的党委书记熟悉了Java ME部门的业务之后，才开始对该部门进行调整，并且调整的幅度不会很大。

Java FX的去留，要取决于Java ME的命运。我们知道，不管Java FX的桌面版做的有多好，在桌面这个领域是肯定收不到支票的。Java FX如果想要挣钱，就必须能够在手机上流畅地跑起来 －－这个事情，不仅仅是改进Java FX本身那么简单，还需要考虑手机的处理能力，以及跑在手机上那个Java虚拟机的效率。

不管是Java EE还是Java ME，都严重依赖于Java SE。如果底层的虚拟机做的不够好，上层的框架搭得再好都是白搭。Sun 公司自己的Java虚拟机，有很多独到之处，执行效率也不错。两家公司合并之后，Oracle之前从BEA那里获得的JRockit估计要遭殃。 Oracle是一家注重实用的公司，因此Java虚拟机下一步将注重于提升服务器端的性能，某些只有桌面端才用得上得功能，其优先级估计就要低一点了。在这一点上，Java虚拟机和GNU/Linux近年来的发展趋势基本上是一致的。

熟悉Java开发的朋友可能会问：NetBeans呢？这可是Sun 公司花了10年心血精心培养常来的宝贝。在下任何结论之前，我们还是先看看2008年Java集成开发环境的市场份额。根据CSDN提供的每年一度程序员大调查数据，在中国这组数字大概是这样的：NetBeans占19.3%，基于NetBeans的Sun Java Studio占4.5%，Eclipse JDT占52%，基于Eclipse的JBuilder占5.5%，基于Eclipse的IBM WebSphere Studio占2.8%，基于Eclipse的BEA WebLogic Workshop占6.5%，IntelliJ IDEA占2.2%，Oracle自己的JDeveloper占1.2%。乍看起来，NetBeans以及基于NetBeans的集成开发环境占了 23.8%的市场份额，似乎是Oracle白白占了个大便宜。再仔细想想，NetBeans是一个免费的产品，Sun 公司大力发展NetBeans，指望的是开发人员通过使用NetBeans将其开发的产品部署在自家的应用服务器等部署环境上，这样才能够卖出产品和服务。在过去四年中，虽然NetBeans的市场份额逐年稳步提升，但是在拉动其他产品方面的作用非常有限。Sun 公司之所以坚持做了下来，是因为过去十年的惯性实在是太大，要想停下来的话不管在内在外都免不了要大折腾特折腾一场。换句话说，这些年来Sun 公司大力发展NetBeans确实保住了面子，但是底下里却输掉了钱包。这种死要面子活受罪的事情，Oracle的Larry Ellison是断然不会做的。

MySQL数据库

2008年3 月，Sun 公司以10亿美元的代价收购MySQL，被Jonathan Schwartz认为是“现代软件史上最重要的并购案”。如此重要的一个角色，在在Oracle与Sun 公司共同发表的新闻稿当中并没有提及。很多业内人士认为，由于MySQL与Oracle的数据库业务之间存在直接的竞争关系，很有可能会被Oracle所抛弃。如果我们将数据库业务这个市场看成一个整体，Oracle与MySQL之间毫无疑问是相互竞争的。但是，如果我们进一步对这个市场进行细分，结论就有可能不太一样。

原MySQL公司的首席执行长官Marten Mickos曾经说过：“如果要在开源软件上取得成功，那么你需要服务于：（1）愿意花费时间来省钱的人；和（2）愿意花钱来节约时间的人。”拿数据库这个市场来说，MySQL所服务的，大部分是第一种用户，小部分是第二种用户；Oracle所服务的，大部分是第二种用户，小部分是第一种用户。MySQL 所拥有的用户数量更多，因为不愿意花钱的人总是比愿意花钱的人多；Oracle所拥有的用户质量更高，因为愿意花钱的都是优质客户。Orqcle更多地被使用于中大型企业应用，MySQL更多地被使用于中小型企业应用，不过这个界限并不严格。因此，MySQL的用户群和Oracle的用户群之间存在一定的重叠，但是重叠的程度并不是很大。Oracle的推广是自上而下的，通过专业广告树立权威形象。一位普通的IT从业人员提起Oracle，可能会觉得 Oracle很强大，什么任务都可以胜任。MySQL的推广是自下而上的，通过口口相传培育用户信心。一位普通的IT从业人员提起MySQL，可能会觉得 MySQL同样很棒，“对付这样的应用足够了”。

但是这并不代表Oracle对MySQL的用户不感兴趣。2005年10月，Oracle收购了与MySQL关系密切的InnoDB。当时 InnoDB为MySQL提供一些事物和外键方面的技术，主要使用于比较复杂的应用当中，对于一般的应用基本上没有什么影响。Oracle收购 InnoDB的本意是希望通过拿走MySQL中的优秀特性来打压MySQL，阻止MySQL进入中大型应用这个市场。遗憾的是开发人员普遍将Oracle 的收购行为理解成对MySQL的恐惧，并且进一步得出MySQL的性能已经足以与Oracle相竞争的推论，反倒帮MySQL做了一次活生生的广告，加速了MySQL的普及。到2008年3 月Sun 收购MySQL的时候，MySQL在数据库业务领域的市场份额已经达到25%以上，更拥有了象Google、Yahoo！、YouTube这样的标杆性用户。

现在一切都顺理成章了，通过对Sun 公司的收购，不管你用的是MySQL还是Oracle，你都是Oracle的用户了。请记住，MySQL被Sun 公司收购之后，基本上是处于独立运作的状态，其现金流还是正的。只要Oracle表示继续支持MySQL数据库，就能够赢得MySQL社区的支持，并在适当的时候向他们提供更好的（要掏钱的）产品或者是服务。在未来的两到三年里，MySQL还是会作为一个独立的产品存在。从长远来看，同时维护多个具有相同或者相似功能的产品会造成用户的困惑。因此，MySQL最终还是需要融入Oracle现有的产品线，只是要等到Oracle将MySQL现有的用户群消化掉而已。

开放源代码

通过这笔金额高达74亿美元的交易，Oracle还将得到一个赠品：按照源代码的行数来计算，Oracle将成为世界上对开放源代码社区贡献最大的实体。从操作系统（OpenSolaris）到编程语言（OpenJDK），从数据库（MySQL）到应用服务器（GlassFish），从开发工具（NetBeans）到办公套件（OpenOffice），这些源代码几乎无所不包。这个赠品来得比较突然，估计Oracle还没有想好要怎样去处理它。

Oracle对开放源代码的态度，可以用四个字来总结：拿来主义。如果一个开源软件足够好用，直接拿过来集成到Oracle的产品中就是了，没有必要为其支付任何费用。用Larry Ellison自己的话来说：“我不能够给开放源代码软件开出上亿美元的支票，因为这并不能够使我们在竞争中得到优势。我们能够做的，别人也能够做。”可惜的是，Oracle收购了InnoDB，并没有拉拢到MySQL的用户；Oracle推出了Oracle Enterprise Linux，也并没有能够拉拢到Red Hat的用户。开放源代码的价值，在于围绕该技术所形成的社区，这个社区包括该技术的开发人员和用户。只有这个社区成了规模，才能够给社区领袖带来经济价值。在这一点上，Marten Mickos看得要比Larry Ellison更为透彻。

和Oracle相比，Sun 公司在开放源代码方面显然拥有更多的实战经验。在过去的四年里，只要是可以开放源代码的软件资产，Sun 公司基本上都开放源代码了 －－ 不仅仅是软件，连其最新版本的处理器UltraSparc T2的设计都是开放源代码的。这也难怪有人这么评论道：“在这场轰轰烈烈的开放源代码运动中，Sun 公司无疑是开放得最为彻底得一个。从处理器到操作系统，从编程语言到开发工具，从数据库到办公环境，无一例外。”问题在于，作为一家挂牌交易的上市公司，开放源代码的举措并没有能够使公司摆脱财务上的困境，最终被Oracle收入囊中。Sun 公司的这些“实战经验”，到底有多少能够为Oracle所借鉴，是个值得进一步探讨的问题。

结语

我于2004年10月满怀仰慕之情加入Sun 公司。在过去的4 年多时间里，Sun 公司一直处于动荡之中。每隔三五个月，就来一次结构调整，让大家紧张一阵。这几年来，大大小小的调整经历了不少，竟然慢慢地也就习惯了。这一次经济危机，心里也知道公司的情况非常紧张，但是没有想到竟然这么快就要被卖掉。就借用《金刚经》中的几句话，作为这篇文章的结语吧。

一切有为法，如梦幻泡影，如露亦如电，当做如是观。

关于作者：

蒋清野，1999年获得清华大学学士学位，2000年获得美国伊里诺大学香槟分校硕士学位，目前是Sun 中国技术社区的高级经理，同时任北京交通大学软件学院的客座讲师。在加入Sun 公司之前，蒋清野曾就职于北京中基超威信息技术有限公司（AMD公司的子公司），负责Linux操作系统的裁减与驱动开发。在此之前蒋清野就职于美国导航与控制公司，负责惯性导航、人工智能和嵌入式系统等多方面的研发。蒋清野的个人博客地址为http://www.qyjohn.net/。

--
 ("`-''-/").___..--''"`-._                         云与清风常拥有，
  `6_ 6  )   `-.  (     ).`-.__.`)                 冰雪知音世难求。
   (_Y_.)'  ._   )  `._ `. ``-..-                  击节纵歌相对笑，
  _..`--'_..-_/  /--'_.' ,'                        案上诗书杯中酒。
 (il),-''  (li),'  ((!.-'                              2000.12.31
______________________________________________________________________


※ 修改:·qyjohn 于 Apr 21 12:22:43 2009 修改本文·[FROM: 119.73.251.*]
※ 来源:·水木社区 http://newsmth.net·[FROM: 119.73.251.*]

• 不支持帮助系统
• 不支持某些Action，包括CUT/COPY/PASTE这样常用的Action
• 不支持OS相关的API，从前是在org.eclipse.swt.internal.win32.OS中
• 不支持键盘事件
• 不支持拖放
• 不支持高级光标
• 不支持System tray（当然，这是web应用）
• Graphics系统跟RCP差距较大，像Color/Font这样的基本元素都是只读的
• 如果你使用了依赖RCP插件的第三方插件，那对不起，你得hack源代码和配置文件让它们依赖RAP插件
  

IcedTea：首个100%兼容、开源的Java

作者 R.J. Lorimer译者 张龙 发布于 2008年6月26日 下午8时42分

社区

Java

主题

开放源代码,

社区,

治理,

许可证

标签

GNU,

Java SE

本周有报道称RedHat发起的IcedTea项目（连同OpenJDK一起），已经通过了Java兼容性测试工具（TCK）的测试，达到了100%的兼容，正式成为首个通过TCK兼容性测试的完全开源（GPL协议）的Java实现。 

本周IcedTea项目到达了一个重要的里程碑——包含在Fedora 9（x86及x86_64）中的最新的OpenJDK通过了TCK严格的测试。这意味着它提供了所有必需的Java APIs并且在行为上与其他Java SE 6实现类似——与Java平台可移植的目标一致。

大家都认为通过TCK测试是一个了不起的成就：

Java TCK是一个复杂的工具和文档套件，用来验证Java实现是否遵从Java规范。它包含80,000多个测试以及100多万行代码。

就像早前在InfoQ上讨论的那样，IcedTea项目通过OpenJDK成为一个100%的基于GPL协议的Java实现，并且使用GNU Classpath项目的相应部分替换掉了余下的5%的私有组件代码。

IcedTea项目由GNU Classpath小组创建，同时由于需要使用开源实现替换掉所有的私有代码，因此一些RedHat开发者也加入其中。GNU Classpath将OpenJDK中的私有代码替换为GPL协议的代码，这使得使用OpenJDK构建的IcedTea更加适合如RedHat的Fedora Linux这样的平台。由于IcedTea的一部分贡献，Fedora 9包含了功能完全的OpenJDK包。 

其他的开源Java实现，如Apache Harmony尚没有通过TCK测试，然而并不是所有的困难都与技术相关。早在2007年4月，Apache软件基金会就向Sun公司发送了一封公开的邮件，希望解决使用TCK测试Harmony平台的关键的许可协议问题；许可Harmony小组以开源的方式合法运行TCK。Sun回复了该公开邮件，他们说还没有决定向Harmony小组授权，因此他们仍无法运行TCK。

IcedTea项目没有像Apache Harmony那样遭受到相同的协议问题，因为Sun已经提供了TCK许可协议的一个特别版本，面向派生自OpenJDK的任何Java实现；这是Apache Harmony所无法获得的东西。

InfoQ将继续报道开源Java实现相关的新闻。

http://www.adam-bien.com/roller/abien/entry/hell_freezes_over_java_7

Hell Freezes Over - Java 7 (JSR-277) Module System will support OSGi

During the general session there was an official announcement - Java 7 Module System (JSR-277) will support both - its own format IAM - as well as OSGi. Great "news" for Java - and it should stop some friction/discussion in the community. So this announcement is double-great :-).

最近家里有点闹心的事，没来更新。

SC 0.1β在sourceforge上停了一年多了（参见2006年3月14日和3月22日两贴），现在重新拾起来完全是因为做那个被cancel项目激励的，从这个项目上得到了pattern上的更进一步的认识，于是思考这些经验是否可以用来重构SC。要感谢水木Java版那些对开源保持热情的年轻的人们，zms、kabbesy、dev、cjmm……，因为他们牵头创建了这个水木自己的开源项目站点：SMTHJava。

目前差不多做成型的是一些基本widget，完全GUI-independent，以及它们的Swing和SWT实现，这些基础widget是用来拼时钟/日历这些高级widget的积木块。想法就是类似IoC那样运行时注册，发现，并启用具体采用哪一套GUI Adapter实现方案（Swing or SWT）。简单介绍几个基本概念：

● Iterator（遍历器）

这是在0.1β里就用到的概念。我们观察一个acceptable的日历组件应该有这么一个特征：可按输入（按钮或输入）转到指定月/年上，尤其是相邻的前/后一个月/年。这个行为往往可以适用到很多组件上，譬如通常用到的table“翻页”行为，譬如VB流行的年代常用的DAO/ADO组件。所以我这里抽象出一种行为叫Iterator，“可遍历”，当然它是一个interface，它包含这么几个最常用的方法：

moveXXX()：如moveFirst/moveLast/movePrevious/moveNext，即这个数据结构是“可游动”的，而且是“可线形游动”的（movePrevious/moveNext，而moveFirst/moveLast是两个特殊的游动方式）。

getXXX()：如getFirst/getLast/getPrevious/getNext，我们知道设计栈（Stack）这种数据结构的时候为方便起见会加上一个peek()方法，意思是让你得到栈顶元素而不将其弹出栈（瞟一眼但不去动它），这里也是类似的意思，得到某个位置上的元素而不移动游标。

getCurrentItem()/setCurrentItem()：顾名思义，得到当前游标上的元素或移动游标到某个元素。这是一种非线性遍历方式。

isRollback()/setRollback()：这个名字不知道是不是起得合适，我的本意是这个遍历器是不是“可循环”的，即到达头或尾再往下遍历是不是可以跳到尾或头开始，如果是循环队列的话需要做模运算确定index。

我们看到“遍历器”实际上是一个增强型的队列（循环或非循环），在java.util包中你也能找到Iterator这个接口，但它是单向线性遍历的，只有next()方法。在这个接口上我写了几个基础遍历器，用于封装对整数的遍历，对List（线性列表）的遍历，对日历的遍历，这几个是GUI无关的组件；在GUI中有继承扩展了几种，如对文本框（尤其是格式化文本框）的遍历，对combo box的遍历。

● IterableWidget（可遍历组件）

Iterator是个什么东东呢？简单的说它就是一个helper，可以用来告诉UI应该怎么做，如果要扯到MVC的话，Iterator就是一个controller，UI是view，Iterator要遍历的东西（比如comobox的item list）就是model了。我定义IterableWidget是这么一个玩意，它将一种UI和一个Iterator绑定在一块，这就成了一种稍微高级一点的GUI组件。我们能够想到的有哪些“可遍历组件”呢？上面说了，显示整数的文本框，combo box，spinner，我要做的calendar界面，可翻页的table，DAO/ADO组件等等。

● IterateAction

IterableWidget仅仅是“可遍历”，要激发它动作需要通过另一个组件（譬如按钮），我定义了一个IterateActionButton的组件用于把一个按钮和它要激发的遍历操作的若干个IterableWidget绑定在一起，这个按钮去激发IterableWidget的helper（即Iterator）进行遍历操作。

● Adapter

这里需要对泛型、Adapter模式和IoC稍微有点了解了。我的目的是想达到GUI-independent，对比Swing和SWT，你会发现它们差得十万八千里，除了Object这个爪哇人都知道的根对象，两者竟然没有交集，那你怎么来搞GUI无关性？怎么抽取共同行为？于是乎，泛型就来了吧？把一个具体的GUI对象适配成我这套GUI library当中的对象，具体要用的时候（比如布局，这个GUI-independent做不了）再getAdaptee()还原成具体的GUI对象（Swing或SWT或其它什么玩意）。不管怎么样，地球人总有一套必不可少的公共组件：按钮、标签、文本框、容器、对话框、窗口……，再高级一点就表格、树……，更高级一点就像我们要做的这个日历等等。widget越基础，行为就越容易抽象。

● 一点puzzle

写的时候往往是反复重构，解耦程度越高，重构的代价就越低，这也符合agile的办事风格。我比较为难的是权衡保留泛型参数的规模上，如果你内部属性的类型要做到“精确”，势必要有较多的泛型参数来约束，这个好处是减少类型检查的hard code，但泛型参数的增加会随着类库的继承和复用层次的增长而增长，这是很讨厌的一件事，因为你会发现为了创建一个对象需要指定N多个你并不关心的这个对象内部属性的具体类型。所以，我妥协了，人是容易妥协的动物，我对一个widget通常只用一个泛型参数（如果它需要用泛型的话），这个参数就是指代它需要适配的那个GUI组件的类型；所有接口，目前只有IAdapter使用了泛型，因为我们需要得到adaptee，其它接口只定义行为；widget内部如果用到composite的widget的话，都用这个widget的接口类型。

以上大概通过代码更好理解一些，代码我放单位的机器上了，过两天传上来。

重新启动的SmartCalendar项目主页在这里，主页快照：