很久没关心Eclipse基金会的动作了,只是不断在使用,不断在开发,不断在教别人使用和开发,然后就是等待Eclipse的下个版本。那么,Eclipse基金会究竟在干什么呢?我不想写篇很长的Blog了,只是随便谈谈最近的几个映像:
1。Eclipse 3.3如果我的推算没有问题的话,今年的第三季度我们就可以拿到正式版的3.3了,3.3好像没有什么太大的动作了,我只记得3.2的时候搞了一个MDC(百万下载挑战),据说在预订一半多的时间里就实现了百万下载量。回头看看Firefox好像几乎没花什么精力下载量就达到千万级别了,不是一个类型的软件确实没法比啊。
看了3.3M6的一些表现,Forms包的外观有些改善,但是不知道有没有结构上的调整;Application扩展点的API改了很多,名字也比原来合理了,不过最近正在开发中的一些项目又要重构了,呵呵;最令人激动还是View终于可以折叠到一边了,而不是原来那样最小化了之后还占很多位置,而且最大化也更酷炫了,得益于View的新折叠方式。
2。越来越重视MacOSXSWT 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])
posted on 2007-04-18 18:53
Brian Sun 阅读(5476)
评论(18) 编辑 收藏 所属分类:
软件