很久没关心Eclipse基金会的动作了，只是不断在使用，不断在开发，不断在教别人使用和开发，然后就是等待Eclipse的下个版本。那么，Eclipse基金会究竟在干什么呢？我不想写篇很长的Blog了，只是随便谈谈最近的几个映像：

1。Eclipse 3.3
如果我的推算没有问题的话，今年的第三季度我们就可以拿到正式版的3.3了，3.3好像没有什么太大的动作了，我只记得3.2的时候搞了一个MDC（百万下载挑战），据说在预订一半多的时间里就实现了百万下载量。回头看看Firefox好像几乎没花什么精力下载量就达到千万级别了，不是一个类型的软件确实没法比啊。

看了3.3M6的一些表现，Forms包的外观有些改善，但是不知道有没有结构上的调整；Application扩展点的API改了很多，名字也比原来合理了，不过最近正在开发中的一些项目又要重构了，呵呵；最令人激动还是View终于可以折叠到一边了，而不是原来那样最小化了之后还占很多位置，而且最大化也更酷炫了，得益于View的新折叠方式。

2。越来越重视MacOSX
SWT 3.3的“New and Noteworthy”可以看到这个趋势。记得我去年与Sun公司的James Bai谈到Eclipse与NetBeans时，我就表达了自己的观点，好像Blog里面也有。事实上，“惯用法和外观”在MacOSX系统上的重要地位是没用过苹果电脑的人无法想象的，Eclipse在Windows确实很漂亮，但是之前的版本在MacOSX上还是远不如NetBeans的。我自己也遇到了这样的问题，我们在Windows上开发有“助记符”的问题，比如文件菜单，应该写成“文件(&F)”，这样F下面有条小横线，用户按Alt-F就可以直接打开文件菜单，但是在Mac上没有这样的设计，Eclipse展示出来仍然是这样，就显得有明显从Windows移植的痕迹。除了Mac的菜单外，Mac的窗体、Mac的工具栏、Mac的任务栏、Mac的快捷键都有很多与Windows不同的地方，Eclipse要加油了啊～～

回到说SWT，3.3在MacOSX上有了不少改善，增加了TrayItem，增加了彩色鼠标指针，还改了一个reparent的bug。

3。Ajax是大方向
前段时间炒作了一条新闻，说Eclipse基金会同时发布了三款用于Ajax开发的插件，这个说法是欠妥的。因为这三个项目都是很久以前就有的，现在把他们拿到一起来说，根本原因就是为了回应现在炒作很凶的Ajax。其中“Dynamic Languages Toolkit”没什么稀奇的，NetBeans也已经做了，但我相信Eclipse在易用性方面一定又是做到最好；“Ajax Toolkit Framework”也就是ATF是三者中最红的，现在要合并进WTP了，是为Dojo、Rico、Zimbra这些API的开发人员提供集成，套用行话说，就是“Ajax开发人员终于有了自己的IDE了（欢呼+大笑）”；唯独只有“Rich Ajax Platform”（RAP）最值得一提。

这是一个与众不同的项目，非常具有前瞻性和远见性，这也是Eclipse一贯的做事风格。RAP的缩写是来自于RCP的，RCP已经家喻户晓了，很多知名项目比如Lotus Notes 8和RSSOwl都是基于RCP的，RCP的程序员也很多，“如遇危难，RCP可以将兵！”但是面对Ajax一夜来袭，很多Rich Client应用程序开始希望自己能够搬到Web上去的，可是怎么搬呢？把Java代码翻译成javascript吗？我们都知道真正伟大的程序员都是在Java平台上的，而Java程序员大都不喜欢javascript这样高效但不严谨的风格，尤其是不好调试这一项，使得javascript项目的成本随规模成几何级数递增，这种事情放在Google这样钱花不掉的公司身上还行，但是要放在小公司上就捉襟见肘了。

所以行业内的专家经过这几年的反复斟酌，得到的结论是，终极的解决方案还是要让程序员手写Java代码，出来的却是javascript效果。那如何实现这样的转变了，有两个方案。一是写一个编译器，首先给出一个限定的Java API库，只有utils包、io包、lang包的少数功能和标准控件，最好是SWT式的，大家都很习惯了，如果程序员仅用这些API（和自己编写的API）写代码，就可以被这个编译器丝毫不差的编译成javascript代码，在本地执行和在Web上执行达到相同的效果，这样完全可以调试，也可以扩展这些API。这种解决方案以Google的GWT为代表。二是写一个服务器，这样就可以用全套的Java API，但是不能用AWT和Swing，再给出一组标准控件，（最好是SWT式的，大家都很习惯了），程序员所写的Java代码其实是在服务器上运行的，服务器根据这段代码的操作，把相应的结果反馈给Client端也就是浏览器，而浏览器以javascript的方式展现和接收事件。这种解决方案的代表，就是RAP。

还要说的一点就是后者其实有个帮手，也算很多Ajax网站的诀窍，就是JSON。JSON是把一个Map（名值对组）序列化成XML的工具，如果这样解释好像没什么新奇的。。。那么好，应广大JSON粉丝的强烈要求，我把JSON的解释改成：“JSON就是一个你在服务器端把JavaObject给它，就能在浏览器端取出一个javascript object的神奇而又强大的工具，而它的实现机制，只不过是把一个Map序列化成XML”！

这两个方案有明显的差别，可以说根本不是一种技术，但是他们很可能都有前途，都是王者之道，一个齐桓公一个晋文公，都有机会成为霸主，也完全有可能鼎足而立，开发人员选择谁，完全是根据项目的情况，甚至有可能。。。开发一个联合的方案。。。把GWT封装成一个Eclipse RAP的插件。

4。看看Summer Of Code
不小心点进了Google的Summer Of Code，之前就已经关注过一些，但是好奇心还没有驱使我点Eclipse Foundation进去看，今天终于按奈不住了。。。先简单介绍一下Google SoC[http://code.google.com/soc/]，其实是这样的，很多开源软件基金会想花钱请一些比较牛的大学生来开发一些代码（这些都是最著名的开源软件，也是最肥的），但是不知道去哪里找大学生。Google的影响力比较大，所以就挑了个头，先把这些开源项目的ideas登上去，让学生们挑，学生再把自己的简历投给Google，Google安排一个统一的时间由开源组织去选，选中的学生由Google撮合双方见面或不见面开发，主要是利用了学生在暑期的80天空闲时间，然后老板把钱付给Google，Google付给学生，中间40天的时候Google还要搞个“期中考试”。。。看了一下Eclipse的ideas，挺惊讶的，虽说这不是Eclipse项目发展的主流，但是也从一定程度上显示了Eclipse的不小野心。

其中我最感兴趣的是“Eclipse Open Office Integration”，它旨在把OpenOffice.org的组件嵌入到Eclipse的编辑器中去，而在此之前，Eclipse已能方便的嵌入Microsoft Office的组件了（得益于ActiveX）。这样的功能如果能实现，对我们平时的开发也是很有好处的。另一个我感兴趣的就是“Eclipse install based manager”，现在的RCP没有自己的安装程序，只是在Eclipse的帮助文档中有一篇制作RCP Install的指南，但这是远远不够的，我花在做安装程序上的时间太多了，不值得，因为这些都是共性的工作。除此之外，我还对“RCP real-time collaboration based upon ECF and Google Talk XMPP-based messaging service”感兴趣，如果Eclipse不做，我们也要做这样的功能。最后要提到的一个好玩的功能就是“NetBeans in Eclipse”，两种插件接口对Java阵营还是不利的，如果我为NetBeans编写的插件能够跑在Eclipse上的话，那NetBeans的新特性就会都变成Eclipse的新特性了（够自私了吧！）

5。RCP仍是无冕之王
Eclipse官网的黄金位置还是留给了RCP，RCP在全球还是有大量忠实粉丝的。不久前发现汇丰银行某个分行的CRM系统是基于RCP的（客户端），不久前又发现英国一个咨询公司专门提供RCP开发的咨询业务，不久前IBM正式进入公测阶段的Lotus Notes 8/Hannover也是基于RCP的，只是为了外观重写了Workbench，不久前。。。被人发现我们的软件也是基于RCP的，而且随时提供RCP方面的咨询和培训。

6。跟Mozilla结个亲家吧
忘了提Eclipse 3.3的又一大特性了，叫做“Moziila Everywhere”，是指在任何平台上都可以创建一个Browser控件但是使用Mozilla内核（及时该平台上没有安装Firefox）。这是怎么实现的呢？其实很简单，它要求你必须安装一个xulrunner，后者是Mozilla的全部内核，包括Gecko布局引擎、Javascript解析引擎、XUL解析引擎和XPCOM，其中每样东西都足够写一本书，有了这些，仅用XUL+Javascript就可以写出一个Firefox来，Eclipse洽是利用了这个特性，用Java连接XPCOM所以创建了一个Mozilla的Browser，但是没有任何行为，包括右键菜单。

这个Browser控件和缺省的Browser控件是不一样的，我们平时见到的缺省Browser控件，在Windows上用的是IE内核，在MacOSX上用的是Safari，在Linux上。。。不知道，所以它是最最简单的浏览器，不具备任何可以定制的功能，除了显示一张HTML页面外，没有任何用处。（你该不会想用Eclipse写一个傲游出来吧）

但是Mozilla内核的浏览器控件就不同了，它意味着如果程序员平时为Firefox写插件的形式，也可以被应用到RCP应用程序上来，设想一下我们拥有一个RCP+xulrunner的平台吧，RCP接收Java扩展，xulrunner接收xul和javascript扩展，那我们的平台——要么叫Fireclipse，要么叫Eclifox——就所向披靡了。即使不利用它的可扩展性，单单就是能保证在不同平台上提供对Web应用程序的一致性展现一条，就足够臭美的了，更可以用写Eclipse插件的形式来限定浏览器的行为。。。。。。唉，刚才是不是说过一个NetBeans in Eclipse啊？把那玩意扔了吧～～

总结。

活活，还真是好久没有写Blog了呢。本来只想谈谈Eclipse基金会的，没想到越说越多，连MacOSX、JSON、Google、Mozilla都说了个遍，是不是说了你的偶像什么坏话，我常干这种事，直接跟我联系吧，我愿意分享我的一切感受和看法。忙了，再聊！

下一个大泡泡
（转载本文需注明出处：Brian Sun @ 爬树的泡泡[http://www.briansun.com]）