NetBeans或吞并Creator 同室操戈为哪般？

NetBeans或吞并Creator 同室操戈为哪般？
[收藏此页] [打印]
作者：IT168 麻地河  2007-05-21 网友评论 4 条
内容导航：
NetBeans与Creator同室操戈 第1页： NetBeans与Creator同室操戈 第2页： Sun与NetBeans姻缘契合 第3页： NetBeans“巧计”入Sun 第4页： 微软的挑战促使Creator的诞生 第5页： Creator与JSF的集成 第6页： 融合意味着结束 第7页： 新生命的开始
 
1. NetBeans与Creator同室操戈
最近这段时间，Sun旗下两款Java集成开发环境，上演着一出同室操戈的“喜剧”。一款是老牌劲旅NetBeans，另一款则是后起之秀Sun Java Studio Creator。NetBeans的“老牌”，从它的历史可以追溯到十一年前的一九九六年可见一斑。而“劲旅”一词，资深的Java程序员们肯定会点头同意。相比之下，Sun Java Studio Creator要年轻许多，这个后来者是二零零一年才被提上Sun的议事日程的，而那时，前辈NetBeans已经5岁了。不过，Creator的成长十分茁壮，在Java Web应用开发领域，有着相当不错的表现，因此，称其为后起之秀丝毫也不为过。
NetBeans与Creator都是Sun寄予厚望的两款Java IDE，一直备受Sun的呵护。手心是肉，手背也是肉。在过去的几年中，Sun似乎未曾偏爱过其中任何一个，两碗水端得很平。NetBeans照旧迈着老牛般沉稳的步伐，随着Java平台的更新换代，不紧不慢地推出新的版本。又或当Sun发明一个什么新技术时，NetBeans也随声附和地往自己身上添加一个插件，保持着和Sun的一致步调。与NetBeans对新技术兼融并蓄来者不拒的宽容态度不同的是，Creator在眼花缭乱的新技术面前表现得相当淡定，除了那些有助于快速可视化开发的技术以外，Creator并不一味追随Java的时尚潮流，而是以Sun为其设定的目标为准绳和尺度，衡量着哪些技术应该包含进来，哪些技术则应该大胆放弃。
Sun的意图是相当明显的，NetBeans是为Java高手打造的精良武器，而Creator则是专为Java初学者搭建的游乐场。NetBeans采用最新的技术，支持最新的平台版本，一个资深的Java程序员，在NetBeans中如鱼得水，可以完成任何Java理论上能完成的工作，开发出精巧的、散发着Java咖啡浓香的、让Java专家们颌首称赞发出会心一笑的应用程序。Creator则没有这么严谨了，初学者无需太多的Java背景知识，一本书没看完就可以充满信心地投入Creator的怀抱。在Creator的游戏场上尽情玩耍，或爬或行，或跳跃或匍匐。只要能摘到Java树上的那枚青果，你的程序就算编出来了，至于是否符合体系结构的要求，有没有冗余或者缺欠的代码，都不太重要。
NetBeans和Creator如此相安无事多年后，平衡终于被打破，Sun开始在两者之间犹豫不决。随着版本的更新，NetBeans和Creator逐渐偏离了预期的轨道。一方面，NetBeans的用户不再满足于过分追求纯粹的Java味道，快速可视化开发所带来的效率的提高，让他们对NetBeans的易用性提出了新的要求；另一方面，随着Java EE 5的发布，Sun启动了简化Java开发的战车。新技术的推出，无不朝着易用性方向发展，越来越多的初学者，经过简单的培训，同样可以编写出有板有眼的、让Java高手挑不出大毛病的Java程序——Creator下JSF应用的开发就是一个明证。种种迹象表明，NetBeans和Creator已经开始出现某种程度的重叠，Creator能做的，NetBeans也能做到，Sun渐渐陷入为同一个市场维护两条功能相似的产品线的尴尬境地。作为一个商业公司，这显然不符合经济原则，资本对利润的追求，股东对红利的期待，或许会迫使Sun痛下断其一臂的决心。
1
 
2. Sun与NetBeans姻缘契合
NetBeans是作为一个教学项目于一九九六年启动的，当初的名称并非NetBeans，而是叫做Xelfi。老程序员们一定不会忘记一九九六年，那时有个誉满全球的IDE，那就是Borland公司的Delphi。很明显Sun是受到了Delphi成功的启示，Xelfi项目的目标正是开发一个类似于Delphi的Java IDE，而且，为了证明Java的无所不能，这个IDE本身的开发语言毫无悬念地选择了Java语言。很快，Xelfi的第一个预览版本在一九九七年发布，虽然是个不成熟的产品，却给当时的Java IDE领域带来一股清新的空气。要知道，那时还是字符界面IDE的王国，尤其是对Java语言来说，Xelfi是第一个图形化的Java IDE，其意义重大而深远。
参加Xelfi项目的那批学生是幸运的，也是敏锐的，他们意识到Xelfi的商业价值，于是在毕业后，他们决定将Xelfi进行到底。找朋友、托关系，他们或求或借，终于弄到Web空间，一家以Xelfi为核心的公司成立了。Xelfi是一个令人非常感兴趣的项目，几乎所有参加过Xelfi的学生都参与到了NetBeans中，直到今天，在NetBeans的邮件列表中，仍然可以看到他们的名字。
要使Xelfi运作起来，必须将其作为一项商业活动来进行。来自企业家Roman Stanek的投资，将Xelfi推上了商业化的轨道。有趣的是，Xelfi最初的商业目标是开发具有网络功能的JavaBeans组件。Xelfi的架构设计者Jarda Tulach给这种组件命名为NetBeans，IDE的目标就是协助开发NetBeans——这就是NetBeans这个名字的来龙去脉。后来，Sun的EJB标准发布，具有网络功能的JavaBeans成为现实，用Xelfi来开发具有网络功能的JavaBeans已是多余。与Sun去竞争显然是不理智的，因此，Xelfi决定接受EJB规范，不过NetBeans这个名称被保留了下来。
一九九九年春，NetBeans DeveloperX2发布，支持Swing。不过，这时的NetBeans一直受到性能问题的困扰，这主要是因为Java平台本身的性能不高。直到一九九九年秋，当Sun发布JDK1.3，大幅优化了Java平台的效率后，NetBeans DeveloperX2才成为Java IDE的一个可以考虑的选择。这年的夏天，NetBeans的开发小组对NetBeans DeveloperX2的结构进行了重新规划，这个更模块化的NetBeans结构，成为此后NetBeans发展的基础。
也许，一九九九年对于NetBeans来说，最重要的事件莫过于Sun的介入了。当NetBeans的开发小组努力工作的时候，Sun正在为市面上缺少好用的Java IDE而发愁，因此，NetBeans引起了Sun的注意。作为Java的发明者，Sun的一举一动备受瞩目，当Sun把目光投向NetBeans，开发小组有种梦想成真的感觉。成为Java发明者的旗舰开发工具，多少公司为此奋斗多年也未能如愿，NetBeans的不懈努力终于迎来了丰厚回报。是年秋天，一个收获得季节，当NetBeans的下一代产品投入beta测试时，NetBeans与Sun的合作协议签订了。
1
 
3. NetBeans“巧计”入Sun
第一个正式采用NetBeans这个名称的是NetBeans的2.0版本。一九九八年，为了推广NetBeans，企业家Roman Stanek率领NetBeans的开发团队，参加了Sun的JavaOne大会。这时的Roman Stanek实际上也是NetBeans团队的队长，因此，推广NetBeans他责无旁贷。Roman Stanek率队参加Java One大会的目的，除了向观众展示NetBeans以外，还有一个更大的野心，那就是吸引Sun的注意力。为此，他设法邀请Jonathan Schwartz来到NetBeans的展台，并安排技术人员演示了NetBeans的功能。Jonathan Schwartz是Sun公司Java技术联盟的负责人，他决定哪些公司可以成为Sun的盟友。Roman Stanek的苦心没有白费，Jonathan Schwartz答应在一九九九年邀NetBeans加盟，于是出现了上文Sun和NetBeans的合作。一九九八年JavaOne大会上的NetBeans是幸运的，更为幸运的是，“介绍”NetBeans加入Sun的Jonathan Schwartz，后来成为Sun的CEO，并且一直关注着NetBeans的状况，使NetBeans获得了来自Sun最高层的强有力支持。
被Sun纳入Java IDE版图后，NetBeans的发展并非一帆风顺。Sun收编NetBeans的原因很简单，Sun没有一个拿得出手的Java IDE，来帮助推广Java语言和平台。Sun自己倒是有IDE，但是，不论是Java Workshop还是Java Studio系列产品，都存在这样或那样的不足，难以使用。因此，在收编NetBeans的同时，Sun还拉拢了Forte，因为Forte的SynerJ IDE和NetBeans一起，是当时最好的两个Java IDE。Sun把这两个IDE融合在一起，推出了一个称为“Forte for Java”的IDE。Forte for Java有三个版本，分别是社区版、互联网版和企业版。社区版是免费的，而用于在Web服务器上开发后端软件的互联网版，以及用来开发大型分布式Java应用的企业版则是收费的。可惜，Forte的表现不尽人意，虽然在Java开发者中还算流行，但一直不温不火，难成Sun所期待的燎原之势。更为糟糕的是，一方面Forte成大气候的希望渺茫，另一方面，用户对新功能的贪婪胃口，却又带来无止境的成本消耗，Forte成了Sun掌中的烫手山芋。
好在Sun眉头一皱计上心来，想出了一个绝妙的主意。将NetBeans据为己有不到一年后，在NetBeans上难有作为的Sun决定放虎归山，而且这次Sun做得相当彻底，因为Sun决定将NetBeans开源。于是，二零零零年六月，NetBeans迎来了其发展历程上的又一重大机遇，这个机遇对于NetBeans来说，其意义或许超过了其加盟Sun公司。
NetBeans的开源是Sun的一石二鸟之计，一方面摆脱了Forte带来的尴尬处境，另一方面，开源又为Sun赢得了开发者的信任，在业界树立起敢于奉献的良好企业形象。尽管Sun的开源举动多少有些政治目的，但客观上，开源将NetBeans带入了一个快速发展的阶段。NetBeans是Sun资助的第一个开源项目，Sun负责开源组织架构的管理和维护，并且为NetBeans建立了一个专门的网站，那就是netBeans.org。开源后的NetBeans势头迅猛，版本的更新速度加快，奖项和荣誉如雪片般飞来，越来越多的工具包被开发出来并加入NetBenas中，而NetBeans一词也逐渐成为出版物中的出现频度最高Java开发工具之一。Sun的开源决策助NetBeans取得了出乎意料的成功。
1
4. 微软的挑战促使Creator的诞生
Sun Java Studio Creator的诞生，看似偶然，其实有其必然性。二零零一年快要结束的时候，Sun的几个高级工程师聚集在一起，讨论是否要开发一个新的Java IDE，于是有了后来的Sun Java Studio Creator。那时候NetBeans已经开源，NetBeans的开发小组度过了艰难的头几个月后，终于与来自世界各地的开发者磨合在一起，正信心百倍地朝着NetBeans的下一个版本前进。
Creator的诞生，与NetBeans的关系其实并不大，而来自微软的挑战倒是促成Creator出台的最主要原因。二零零一年的时候，微软的VB和ASP大举攻城略地，VB以其快速和易用的特性，成为许多刚刚走出校门的大学生的首选开发语言，而ASP也在Web开发方面独占鳌头。Sun看在眼里急在心里，眼看着有着更良好技术架构的Java，却不能在与VB和ASP的角逐中稍占风头，Sun明白，自己缺乏一个对初学者有吸引力的集成开发环境。这方面，恰恰是微软的强项，从操作系统到应用软件，微软的产品最为人称道的就是其易用性，复杂的操作系统安装、数据库设计、文字排版甚至项目管理，只要用上微软的软件，一切都轻而易举。
所以，Sun推出Creator的目的现在非常清楚了，那就是模仿微软Visual系列开发工具在易用性方面的特点，给Java初学者提供一款快速可视化集成开发环境，以吸引那些初出茅庐的程序员，同时给准备转投Java阵营的VB/ASP开发者一个弃暗投明的更充分理由。
也许有人会问，NetBeans不行吗？确实，那时的NetBeans并不适合初学者，也不适合习惯了在微软可视化开发环境中拖拖拉拉的VB/ASP程序员，因为NetBeans是面向Java资深程序员的，他们喜欢在一个文本编辑器中如痴如醉地敲入一行行代码，而不是用鼠标拖过来放过去。所以，尽管开源后的NetBeans已经崭露头角，并且表现出良好的发展前景，但Sun仍然需要为Java初学者们准备一台傻瓜相机，好让他们只需简单地按动快门，就可以拍出曝光适度的第一张Java照片。
支持快速可视化开发的IDE用起来容易，可是要开发这样一个IDE，却不那么简单了。另起炉灶几乎是不太可能的，一方面投入过于巨大，另一方面，也是最重要的，微软不会善意地停下来，等着Sun迎头赶上。因此，自然而然地，Creator的开发小组想到了NetBeans这个前辈。以一款现有的IDE为基础，对其加以修改，以适应新的需求，无疑是更为理智的做法，既能降低开发难度、节省开发成本，又能赢得更多时间，尽快缩短和微软的差距。就这样，NetBeans成了Creator的出发点。
可惜，即使有NetBeans打底，事情也没有想象的那么简单。最理想的方式当然是直接修改NetBeans的代码，甚至架构，使其具备支持快速可视化开发的能力。这样，只需用一套与NetBeans不同的GUI来重新包装，就可以炮制出一个全新的IDE。但是，在已经开源的NetBeans上，这样做非常困难，因为底层代码的任何一点修改，都会影响来自世界各地数量庞大的开源开发者，所以几乎是不可能的。因此，万般无奈之下，Creator开发小组只好从NetBeans的代码库中形成一个分支，在这个分支上开发Creator，而让NetBeans继续沿着自己既定的路线前进。
 
5. Creator与JSF的集成
熟悉JSF的人们一定记得，Creator诞生的二零零一年，也是JSF生命的起点。二零零一年五月，Sun在JSR＃127中提出制订一个以用户界面框架为目标的规范，经过半个月的投票表决，SE/EE执行委员会以十票同意、五票反对和一票弃权的结果批准了JSR＃127，这就是JavaServer Faces规范，即JSF。开发Creator的想法比JSF规范稍晚几个月，因此，当Sun决定为Creator立项时，JSR＃127已经得到了批准，也就是说，Creator完全可以面向JSF技术。
Creator开发小组正是这样决定的。Creator的一个主要目标对象是VB/ASP开发者，而JSF又标榜以简化Java Web开发为己任，因此，Creator的第一个版本，顺理成章地定位为基于Java语言的、JSF应用的快速可视化集成开发环境。与NetBeans不同，Creator在其界面上表现出诸多支持快速可视化开发的特征，例如供拖放组件用的组件面板，方便管理数据源、EJB和Web Services的服务器导航器，上下文敏感的动态帮助，简单的应用服务器部署以及Web应用的调试工具等等，不一而足。
Creator的开发肯定是被JSF规范拖了后腿。JSF规范也许是Java历史上最“难产”的规范之一。二零零一年五月底，JSF专家组成立，着手制订规范文档。历经多次的讨论和修订，JSF规范的1.0版，在差不多三年后的二零零四年三月，才得以面世。Creator既然是用来开发JSF应用的，当然必须要等到JSF规范正式出台后，才能竣工，因此，直到二零零四年六月，也就是JSF 1.0发布后三个月，Sun才向公众宣布Sun Java Studio Creator的面世。
在Creator中，Sun将JSF应用的开发简化到了前所未有的地步。Sun在Creator中显示了对初学者的关怀，缺省情况下，Creator的安装包括了一个数据库和一个应用服务器，并且是已经配置好的，当Creator启动时，配套的数据库和应用服务器也同时自动启动。这使得初学者不用为配置开发环境而大伤脑筋，很多初学者往往因为无法成功配置数据库或应用服务器而放弃使用某种IDE，Sun试图通过绑定这两种服务器来避免这种情况的发生，可见Sun在Creator上是费尽苦心了的。
不用为开发环境烦恼，然后开发者才有心情体验Creator的快速可视化JSF应用开发。笔者曾经有幸试用过Creator，确实非常优秀，在Java语言环境下，第一次像在微软的Visual Studio中那样，用鼠标拖放组件，给人一种非常奇妙的感觉。JSF的组件被放置在一个组件面板中，创建一个JSF页面后，从组件面板中拖放一个组件到页面上，后台自动生成相关代码。那时笔者正在使用JBuilder开发一个JSF项目，试着比较JBuilder中手工编写的代码和Creator自动生成的代码，发现有许多不同之处，Creator的代码要复杂得多，有很多代码是笔者所不能理解的。可见，Creator与JSF的集成非常紧密，几乎发挥了JSF的全部特点。
与JSF高度集成，在后续的Creator版本中依然保持得很好，二零零五年初发布的Creator 2支持JSF1.1，随后来发布的Creator 2的更新版本Creator 2U1则已经可以使用JSF的最新版本1.2了。不管从哪个方面考察，Creator都是最优秀的JSF应用开发工具，因为它们的目标相似，志同道合，所以配合起来天衣无缝。“designed to be tooled”的JSF唯有依靠Creator才能一展歌喉，而Creator也凭借JSF嘹亮的歌声，赢得了Java Web开发者青睐的目光。
1
 
6. 融合意味着结束
各自度过了几年平静而美好的时光以后，NetBeans和Creator终于走向了融合。当NetBeans 5.5发布时，开发者们惊喜地发现，一个名为Visual Web Pack的工具包赫然出现在下载清单中。官方网站上对VWP的介绍非常简洁：通过拖放组件来可视化地构建Web应用，不过，一行“将Creator项目移植到VWP”的文字，隐晦地道出了VWP的真实身份和目的。其实，用融合来描述NetBeans和Creator的关系是不恰当的，准确的说法，或许应该是吞并，NetBeans吞并了Creator。因此，NetBeans和Creator的融合，可能意味着Creator的结束。
事实确实如此，安装VWP后，在NetBeans中即可以开发JSF应用，其操作界面和Creator完全一样，甚至连VWP的某些文档，都借用了Creator的。整个NetBeans和Creator的开发社区很快都明白了这样一个事实，于是，论坛中关于这一事件的讨论此起彼伏。
Creator向VWP的过渡，除了商业上的不得已，其实也有技术上的考虑。前面说过，NetBeans的过人之处，是时刻紧跟Java标准和版本。当JDK 1.5发布时，NetBeans发布了5.0版本来支持它，然后，当Java EE 5发布时，NetBeans又发布了5.5版本呼应。而Creator呢，由于是从NetBeans 4.1的代码库分支出去的，并没有享受到NetBeans对新技术快速支持所带来的好处，甚至不支持JDK1.5。本质上，Creator只是NetBeans部分模块的一个新包装，这个新包装的初衷是给用户提供NetBeans所不具备的快速可视化开发特性，但是，当NetBeans从3.6一路发布到5.0时，NetBeans对快速可视化开发的支持，已经今非昔比了。
所以，从技术上看，将Creator作为NetBeans的一个插件是更合理的解决方案。开发一个NetBeans的工具包远比开发支持JDK 1.5的Creator新版本容易，而且，这个工具包能够搭上NetBeans的快车，紧随Java标准和版本的步伐，充分利用Java新技术和新版本带来的好处。于是，Creator小组没有继续开发Creator的下一个版本，而是给NetBeans送去了一份大礼，那就是NetBeans 5.5中的Visual Web Pack。
Creator向VWP的转变相当成功，VWP对Creator功能的覆盖率到达了百分之九十。虽然还有百分之十的遗漏，例如对Web service的支持，对Portal开发的支持等，但VWP承诺，在其下一版本中，将实现这些遗漏的功能，这样，Creator的用户就可以完全转向NetBeans＋VWP了。
1
 
7. 新生命的开始
VWP的出现，对NetBeans的用户来说，无疑是一件喜事，不过，Creator的用户就不免有些伤感了。毕竟Creator是一款非常优秀的Java Web快速可视化开发工具，曾伴随着开发者走过了很多项目，大批开发者对Creator爱不释手，甚至有人在论坛上发出“I miss you，Creator”的叹息。
但是，感情归感情，Creator其实也有不足，转移到NetBeans是其更好的出路。Creator的开发一直滞后于JDK的版本，而且对新技术的跟进速度也过于缓慢。另外，为了简化开发环境的配置，Creator捆绑了Sun的Application Server，这也是Creator所支持的唯一的应用服务器，在应用服务器层出不穷的今天，缺乏对应用服务器的选择权力，是Creator用户最大的遗憾之一。这方面，NetBeans就要开放得多，包括Tomcat、JBoss、Websphere、Weblogin在内的主流应用服务器，都可以在NetBean中使用。
再有，Creator是纯粹的Web开发工具，非常专业，但不够广博，不支持 Web service的开发，不支持EJB的开发，也不能运用UML技术，如果要做这些事情，Creator用户不得不利用其他开发工具。而这些，在NetBeans中一应俱全，用户只用一个IDE，就能完成所有的工作，并且享受高度集成所带来的便利。
保持两套IDE所带来的另一个不便，就是项目的移植，而这种移植，多半是从Creator往NetBeans方向进行，因此，Creator用户经常要为项目能否成功移植而担忧。NetBeans和Creator合二为一后，这项工作不再需要，开发者可以集中更多的精力编写他们的程序。
虽然Creator的消亡还没有成为事实，但是，趋势已经非常明显，在netBeans.org上，关于NetBeans下一版本6.0的讨论如火如荼，而Creator的下一版本Creator 3则要冷清得多。已经有几篇关于停止Creator开发的Sun技术人员博客见诸互联网上，Sun在论坛中所作的调查结果也显示，百分之九十以上的用户支持Creator向Visula Web Pack的转变。甚至有性急的开发者，早以摸索出从Creator向VWP移植项目的路子，非常热心地向Creator用户介绍着。
美好的事物总是令人怀念，Creator用户的伤感，是对Creator成就的最高评价。理智上，我们希望看到Creator的结束和VWP的诞生，但是，感情上，我们更愿意相信，Creator其实没有离开我们，这条可爱的小毛毛虫只是长大了而已，它褪去身上的毛衣，化作一只美丽的蝴蝶，轻轻降落在NetBeans这棵树上，扇动着翅膀，给我们送来阵阵花香。
1