节选borland传奇

第五章 逆转的奇迹--Borland JBuilder的战斗发展史 "没有JBuilder，Borland就不可能拥有今日的荣景！" Java的快速兴起和成功是谁也没有预料到的，即便对于SUN自己似乎也是一个极大的意外，但是成功者一定是果断而且行动迅速的。当SUN察觉到Java的光明未来之后，便立刻开始大力推销Java。SUN的总裁McNealy先生数年来苦于没有直接和Microsoft 对抗的机会，这下在Java的身上似乎找到了契机，当然更重要的是SUN接下来的一连串行动都被证明是正确而成功的。这些行动包括和各种厂商合作；与Addison-Wesley 公司合作出版一系列畅销且成功的Java书籍；在各大媒体占据版面发表所有与Java相关的文章、专栏等；快速培养Java使用者的基础，吸引大众对于Java的兴趣。这完全是Microsoft一向无往不胜、攻无不克的手法，SUN也发挥得淋漓尽致，并且"以彼之道还施彼身"。更重要的是McNealy立刻果断地投入大量的研发资源，不断地改善Java，终于使Java从1995年开始展露锋芒，并且快速地成为业界焦点，自此展开了PC发展史上最大规模对抗Microsoft的争霸战，也改变了许多软件开发的习惯和方向。当然对于Borland来说，Java的发展史也是一场惊涛骇浪的生死之战，是Borland从未经历过的大规模集团军混战。 对于Borland来说，事情并没有那么顺利。1995年，当Java开始起飞时，Borland并没有预料到Java成长的速度会如此之快。Borland一开始只是把Java当成C/C++的延伸，因此只在Borland C/C++5.0中加入了支持Java的P1ug-In。不过Borland很快就发现事情并不是如此简单，因为除了Java的Plug-In反应并不好之外，也发现Symantec很快在Java开发工具找到了新舞台，而且发展得相当快速。在Microsoft对Java的态度未明之前，无疑Symantec占据了先机，Borland这才警觉到自己的失策，Java大会战一开始Borland就已经落后了。Borland如何才能在下一场最重要的开发工具大战中进行反攻呢？ Java开发工具初期的争战 当Symantec从C/C++开发工具市场大撤退之后，Eugene Wang不愧是相当高明的开发工具好手，立刻察觉到尽管在C/C++市场遭遇失败，但利用原有力量却可以在即将茁壮成长的Java市场上扳回一城，因此立刻率领原先Symantec C/C++的开发团队快速进入 Java开发工具的领域。Eugene很快以当初Symantec C/C++的集成开发环境作为基础，开始开发Java开发工具，这就是后来著名的Visual Café。 Symantec几乎是第一个介入Java开发工具的软件公司，又利用了Symantec C/C++的基础，因此在1995年，当Java获得愈来愈多人的注意之后，Symantec也准备好了她的第一个Java开发工具--Visual Café。1996年10月，Symantec赶在JDK 1.1之前正式推出了Visual Café。虽然当时许多人批评Symantec为什么不等到JDK 1.1之后再推出，以支持最新的JDK标准(因为当时的JDK 1.0x版本有许多的问题)，不过这些批评并没有妨碍Visual Café的成功。 由于当时许多软件人员急于投入Java的学习行列，因此当Symantec推出了Visual Café 之后，立刻在市场获得了极大的成功。特别是在Java学习市场和教育市场，Visual Café几乎是以席卷市场的姿势迅速占据了Java开发工具第一名的地位，成为炙手可热的产品，而Symantec公司也一扫在C/C++开发工具被挫败的怨气，再次成为开发工具市场的领导厂商。 由于当时Microsoft对于Java采取敌视的态度，因此几乎不可能推出Java开发工具，而Borland也还正陷于C/C++的苦战之中，尚未查觉到Java的潜力。至于另外一个死对头Watcom则已被Sybase并购，无法在开发工具市场再成气候。这对于Symantec来说简直是天赐良机，一个可以独打Java开发工具市场的绝佳机会。剩下唯一的威胁是SUN 要推出的Java开发工具。但是Symantec已经抢得市场先机，而且已经成为领先者，只要好好的把握，就能够以逸待劳和SUN对战。在这个Java开发工具萌芽的阶段，Symantec 似乎是占了绝对的优势，不过很可惜的是接下来Symantec也接连犯了几个错误，逐渐失去了取得的优势。 首先是当Visual Café推出之后，Eugene Wang便离开了Symantec自己开公司做生意去了。这对于Visual Café有着相当大的影响，因为Symantec靠着Eugene Wang的技术能力和眼光，才能够和Microsoft、Borland和Watcom在C/C++开发工具市场对抗； Eugene Wang又独具慧眼打造了第一个Java开发工具Visual Café。Symantec应该在 Visual Café获得初期的胜利之后再次借重Eugene Wang的功力继续攻城掠地，但是 Symantec居然让Eugene Wang离开，立刻少了开发工具掌舵的大将。 第二个错误是Symantec当初为了尽快推出Visual Café以抢占市场先机，因此集成开发环境是使用C/C++语言撰写的。这造成了数项缺点，其一是由于使用了C/C++来撰写可视化窗体设计家(Visual Form Designer)，因此程序员在设计时看到的可视化效果和真正Java程序执行时的效果是有一些差异的；其二是为了维护Java的控制组件程序代码和以C/C++撰写的可视化窗体设计家保持同步的状态，在可视化窗体设计家产生的原始程序代码中内嵌了一些Visual Café控制卷标(Control Tag)。这些控制卷标并不是Java的程序代码，只是为了可视化窗体设计家使用。如果程序员不小心修改或是删除了这些控制卷标，就会造成Visual Café的可视化窗体设计家的失效。这是非常严重的缺点，Symantec应该在Visual Café 1.0之后立刻改善这些问题，然而Symantec 却似乎一直无法有效地加以改善。当然，问题的根源在于Visual Café的集成开发环境是使用C/C++语言撰写的，要完全改善这个问题，Symantec必须使用Java语言重新改写集成开发环境，这正是Borland后来采取的策略。不过使用Java撰写集成开发环境也是非常冒险的行动，Borland后来因此付出了沉重的代价。Symantec之所以没有如此做，大概也是因为当时的Java并没有成熟到可以如此做的地步。不过SUN显然不这么认为，其对Java信心百倍，不久就推出了SUN的Java开发工具，Java Workshop。 当Java成功地掳获了开发者的心之后，对于Java开发工具的要求便与日俱增。虽然 Symantec已经推出了Visual Café，但是许多人仍然希望Java的正宗厂商SUN能够推出 Java开发工具，让所有想要学习、使用Java的开发人员能够使用最标准的Java开发工具。当然，许多人也希望SUN能够使用Java撰写Java开发工具来向世人证明Java的能耐，让质疑Java能力的人以及Microsoft闭嘴。当然，SUN在Java成功之后也信心满满地宣布了SUN的开发工具计划，以满足广大开发人员的需求。McNealy多年来进攻Microsoft 地盘的希望似乎即将出现光明的未来。 之后不久，在万方期待之下，SUN终于推出了Java开发工具SUN Workshop。在Java Workshop即将推出之前，Symantec非常地紧张，因为这关系到Symantec是否能够在Java 开发工具市场站稳脚跟。我记得在Java Workshop推出之际，所有的媒体、杂志都大幅报道Java Workshop，SUN也大力地宣传和促销Java Workshop。从当时的气势来看， Java Workshop颇有"千秋万世，一统江湖"的味道。我所认识的许多朋友不管是用买的、借的、下载等和--嗯--那个的……各种手段，都热切地想取得一套Java Workshop 来玩玩。不过丑媳妇总要见公婆的，在许多人使用了Java Workshop之后，才发现它不但执行缓慢得像乌龟一样，而且问题多多，和一般的PC开发工具水准比起来简直是差了十万八千里。看来Java Workshop只适合使用在昂贵的SUN工作站计算机上，而在当时大多数人使用的PC上则根本跑不动，除非是拥有异于常人的耐性。 Java Workshop雷声大雨点小，不久之后就人气溃散了。许多原来对Java有信心的人在用了Java Workshop之后，也开始质疑Java是否适合使用来开发复杂的应用程序？是不是只适合用来撰写Applet？是不是只适合使用在SUN的工作站和计算机之上？虽然之后SUN仍然很努力地推出Java Workshop 2.x的版本，希望一洗Java Workshop 1.x的恶名，但是仍然无法挽回Java开发人员的信心。至于其他仍然对Java有兴趣的人则转而使用Symantec的Visual Café，让Visual Café进一步地扩大了市场占有率，也让Symantec吃了一颗定心丸。当然也有许多Borland的支持者开始强烈地期望和要求Borland能够推出最好的Java开发工具。 SUN在Java开发工具市场大溃败之后，才了解到PC开发工具市场和Solaris开发工具市场不一样。在Solaris上SUN是一家独大，但是在PC市场上可是百家争鸣，竞争对手一个比一个强悍。SUN不了解PC开发工具市场的特性，以为靠着Java正宗的招牌就可以通行无阻却是大错特错，并且在当时被Microsoft讥笑不懂得开发软件，这也是因为 SUN经常讥笑Microsoft不懂得开发操作系统，看来在当时SUN也不必五十步笑百步。 SUN在Java开发工具市场弄得灰头土脸之后，不得不专心开发Java语言和JDK函数库，并且在Java语言更为成熟之后开始想要开发Java的组件技术，因此开启了稍后和Borland 合作共同开发Java Bean的功能规格，再进而和Borland共同研发JDK的规格，最后更对Borland的JBuilder发生了强烈的兴趣，甚至想并购Borland。当然这都是因为后来 Borland展现在了Java方面高度的技术，让SUN从肯定到折服的原因所致。 Borland的Java艰辛奋斗 "事情并没有这么顺利"，Borland当时的R&D主管这么说，并且充满了焦虑。当Borland 警觉到Java的潜力之后，Visual Café早已成功地上市，SUN也准备推出Java的开发工具。当时Borland正逐渐从C/C++市场失去王者的地位，财务上也开始出现经营赤字，整个公司正陷于一团混乱的情形中，似乎已经没有额外的资源可以投入Java的研发。在起步落后，又缺兵少粮的情形下，Borland似乎即将失去进入Java市场的希望。 好在稍后的Delphi一炮而红，让Borland大赚了一票，也稳定了军心。Delphi为Borland 注入的资源也很快让Borland激活了Java研发小组。虽然Borland已经落后许多，但是 Borland知道绝不可以失去这个市场，因为Java的市场没有Microsoft式的寡占，Borland 有希望在Java市场比Borland C/C++、Delphi等更成功。此外，Borland更需要在Delphi 这条产品线之外开拓其他的收入来源，否则只靠Delphi产品，公司仍然无法成长得更为茁壮，以和其他的软件公司竞争。 在1994、1995年间，Borland正式成立了Java研究小组，开始研发Java的技术，准备开发Java开发工具。这个Java开发工具的内部研发名称便是Latté。一开始Latté小组的研发资源并不够多，因为当时的Borland是在风雨飘摇之中，无法注入足够的资源到Latté小组。因此在Latté开始开发的初期进展得并不顺利，进度很缓慢。一直到了Borland靠Delphi浴火重生之后Latté小组才有了足够资源，研发的进度才开始加速。不过与竞争对手们比起来，Borland在Java方面的确是相当落后的，几乎是跑在最后的参赛者。不过幸运的是Java开发工具之战似乎是一场漫长的马拉松比赛，除了一开始的表现之外，更重要的是比谁能够撑得比较久。事实上看Borland如何在Java 竞赛场上反败为胜、一一打败强者，进而成为Java开发工具王者的过程是相当精彩的，而JBuilder小组使用的竞争策略更值得我们玩味和学习。 依我个人的眼光来看，在Borland开发Java开发工具的过程中经历了数个不同的阶段，每一个阶段都有着非常激烈的竞争，有着成功者和失败者。只是有的失败者仍然坚持竞争下去，有的却随风消散。JBuilder最终能够成为王者，除了是因为愈挫愈勇、 Borland没有退出Java市场之外，还在于Borland在开发JBuilder 3时下了一个关键性的决定，以及在JBuilder 3之后每一个版本都有明确的目标，终于在JBuilder 4之后慢慢成为市场第一的领导者。当然这长达数年的争战过程是非常艰辛的，不过这段历程正是整个Java开发工具逐鹿中原的写照史。 第1阶段--Java JIT编译器的战争 Borland也许不是最晚开始研发Java技术的厂商，但是明显地落后于其他竞争对手则是不争的事实。Borland在Latté万事尚未具备的情形下，展开Java竞赛的第一步便是从Borland传统的拿手绝活开始，那就是从Java JIT编译器开始出发。不过由于Borland 当时对于Java技术尚未拥有良好的掌握，因此一开始是和Pascal的祖师爷Dr. Niklaus Worth合作，由Dr. Niklaus Worth以及他的学生们为Borland研发Java JIT编译器，而Borland本身的Latté小组则平行地开发Latté其他的功能。由于当时Java已经逐渐在校园流行，而且吸引了许多学术研究的兴趣，Dr. Niklaus Worth以及他的学生们很早便开始投入Java相关的研究。因此当Borland找上门之后，自然便一拍即合。 Borland缩短了开发时程，而Dr. Niklaus Worth研究小组则乐得有人赞助研发费用。 Dr. Niklaus Worth研究小组的第一个作品就是在1997年初左右推出的Java JIT编译器，这个由Dr. Niklaus Worth研究小组研发的JIT编译器可以让编译后的Java ByteCode 执行速度比当时SUN的Java编译器以及Symantec的JIT编译器快了数倍。Borland宣布此JIT编译器之后立刻震惊了Java界，因为当时缓慢的Java执行速度是所有使用Java 的人都希望能够立刻大幅改善的。而Borland推出的Java JIT编译器似乎给所有Java 开发人员看到了未来的希望。虽然严格地说当时即使是使用Borland最新的JIT编译器编译Java程序，其执行速度仍然是很"龟速"的，但是对于使用Java来学习程序设计或是撰写、执行一些小的Applet来说仍然是很好用的。因此当Borland一推出此JIT编译器之后，便立刻打响了Borland在Java界的知名度，所有Java开发厂商也开始视Borland 为认真的竞争对手。否则以当时Borland的气势来看，除了Delphi之外，Borland几乎已经一无所有了。 Borland在Java的处女作Java JIT编译器一炮而红，立刻吸引了当时浏览器霸主Netscape 的注意。由于当时Netscape大力支持Java以便和Microsoft竞争，因此非常需要有品质精良的Java JIT编译器内建在Netscape之中，以顺利且快速地执行Java Applet，增加Netscape的竞争力和吸引力，突显与Microsoft IE的不同。不久之后Netscape便找上了Borland，希望能够在Netscape中附带Borland的Java JIT编译器。 对于Borland来说，这又是一个千载难逢的机会。因为这不但证明了Borland在Java技术的努力成果，更重要的是Netscape在当时是不可一世的软件公司，全世界有数百万的使用者。这意味着一旦Netscape内建Borland的Java JIT编译器，Borland在全世界将立刻拥有数百万的Latté潜在使用者，对于Borland来说是好得不能再好的条件了。因此Borland立刻答应了Netscape的提议，让Netscape搭配Borland的Java JIT编译器。但是这一举动也立刻牵一发而动全身，进而导致了Java JIT编译器的大混战。 在Netscape和Borland达成了协议并且开始出货之后，却引起了Symantec的忧虑和不满。因为当时Symantec是Java开发工具的老大，而Borland连个Java开发工具都尚未推出，可是Netscape却跑去使用Borland的Java JIT编译器，这不是让全世界都知道 Borland的实力并且让Symantec脸上无光吗？为了颜面以及避免失去Java开发工具的市场，很快Symantec便决定开始反击。Symantec立刻也集中资源投入Java JIT编译器的研发，开发出比Borland Java JIT编译器更快的Symantec JIT编译器，并且准备开发一个直接把Java ByteCode编译成原生Windows程序代码的Java编译器。就在Borland Java JIT编译器风光不久之后，Symantec也宣布了新的Java JIT编译器。Symantec 的Java JIT编译器比Borland Java JIT编译器更有效率，编译后的Java ByteCode执行效率比Borland的快了2~3倍。 在Symantec Java JIT编译器宣布之后，又轮到.Borland脸上无光了。才刚和Netscape 谈好合作条件，没有想到效率王位还没坐热就立刻被Symantec踢了下来，这如何向 Netscape交待？因此Borland立刻进行改善JIT编译器的研发工作，力图再次超越 Symantec。果然Borland的努力没有白费，不久之后Borland的JIT编译器又打破了 Symantec JIT编译器创下的效率纪录。自此Borland和Symantec便展开了Java JIT编译器的"竞速"比赛，不断地试图打败对方。也由于Borland和Symantec的JIT竞赛，当然更重要的原因是Java的执行速度在当时实在是太过缓慢，引起了IBM、Microsoft以及SUN在Java编译器方面的研究。 Symantec在当时不愧是Java开发工具的王者，在和Borland几次的JIT编译器交手之后，便开始逐渐地占了上风。由Dr. Niklaus Worth研究小组研发的Java JIT编译器也逐渐不再是Symantec的对手。至此Borland决定收回Java编译器的技术，开始自行研发。Borland发觉光是和Symantec在Java JIT编译器竞争没有多大用处，当务之急是赶快推出自己的Java开发工具。因此Borland开始退出和Symantec在Java JIT编译器的竞赛，以求全速催生Latté。当然Borland退出JIT编译器的第一阶段战争之后的影响是不久之后Netscape便不再使用Borland的Java JIT编译器，改为使用Symantec的 Java JIT编译器。至此Symantec终于获得了JIT编译器第一阶段的战争胜利，保住了 Java开发工具第一厂商的颜面。但是Symantec真的获胜了吗？那可不能断言，因为JIT 编译器战争才刚开始。 在Symantec的Java JIT编译器打败了Borland的JIT编译器之后，Symantec便把脑筋动到了SUN的身上，希望SUN也能够使用Symantec的Java JIT编译器，把Symantec推向Java 核心技术的领导厂商宝座。不过Symantec的盘算显然是落空了，因为SUN已经决定收购一家专门研发Java编译器技术的软件公司，并且准备开发自己的JIT编译器，那就是后来的SUN HotSpot编译器技术。另外Microsoft和IBM也开始加入了Java JIT编译器的竞赛之列。IBM为了和SUN争夺Java领导者的地位，不但自己研发IBM的JDK，甚至也研发IBM的Java JIT编译器。严格地说，当时IBM的Java JIT编译器品质比SUN提供的好多了，不但稳定而且执行速度比SUN的快了许多，让SUN也颜面无光，很不是滋味。甚至可以说IBM的Java JIT编译器品质不会比Symantec的Java JIT编译器差到哪里。 更麻烦的是Microsoft为了让IE能够和Netscape竞争，也可以执行Applet，因此也开始研发精良的Java JIT编译器。特别是当Microsoft得到了Anders Hejlsberg之后，在编译器技术方面有了重大的突破。虽然Microsoft的JIT编译器一直不像其他厂商的 Java JIT编译器那么符合标准，但是其品质却是相当的精良。在Microsoft不断地改善之下，依我当时的测试，经其编译后的Java ByteCode执行的速度是最快的，连IBM 和Symantec的JIT编译器都不是对手。因此从我的观点来看，在这个Java JIT编译器的阶段，应该是Microsoft获了冠军。要不是Microsoft没有持续支持最新的JDK标准，又混杂了一些Microsoft自己的东西，到最后很可能使用最为广泛的Java JIT编译器反而就是Microsoft的JIT编译器。 至于Symantec，在取得了JIT编译器表面上的优势之后，立刻又把重点放在了开发直接把Java ByteCode编译成原生应用程序的原生Java编译器。稍后Symantec成功地开发出了这种编译器，让Borland大为紧张，并且准备跟进。而Symantec也把这个原生 Java编译器加入到Visual Café中，成为一项吸引人的功能。不过很快地这个功能却引起了许多Java使用者的批评，因为他们认为这违反了Java"Write Once，Run Everywhere"的精神，如此一来厂商必须为每一个不同的平台开发原生Java编译器，这会造成Java应用程序在不同的平台执行的反应不一致的现象，又陷入C/C++语言开发的应用程序在不同的平台表现不一的相同问题。后来连SUN也不赞成这种做法，当然这是因为SUN想力推自己的HotSpot编译器技术。因此原生Java编译器在风行了一阵短暂的时间之后就不再吸引人注意了，而Borland原本为JBuilder开发原生Java编译器的计划也因此而打住。 Microsoft VJ++的威胁 1996年，Anders Hejlsberg来到Microsoft之后的第一个作品即将推出，那就是 Microsoft VJ++。VJ++的即将推出，对于许多软件公司而言都是一个很大的震撼。对于SUN来说，这是Microsoft在Java领域的挑战。在SUN自己的Java开发工具不争气的窘境之下，又得面对擅长开发工具的Microsoft，特别是由Anders领军开发的精品。对于其他的Java开发工具厂商来说，也是提心吊胆。Visual Café在JBuilder、 Visual Age For Java陆续推出之后市场占有率已经慢慢地被瓜分，现在又得再次面对 Microsoft的竞争，昔日Symantec C/C++失败的阴影又缠上了心头。而Microsoft的死对头IBM更是在VisualAge For C/C++、VisualAge For BASIC连番失败之后，好不容易推出了VisualAge For Java，准备在Java开发工具市场打一场好球赛，没有想到现在Microsoft又来搅局。 对于Borland来说，这个消息更是令人不安，因为Borland本身的Java开发工具仍然处于研发阶段，还没有推出，而且看样子将会是市场上最后一个推出的Java开发工具，落后主要竞争对手已经很多了。现在Microsoft居然更早一步推出Java开发工具，而且是由Anders Hejlsberg主持开发的。Borland当然知道Anders Hejlsberg的实力，自然不敢轻视VJ++的影响力。更麻烦的是在VJ++推出之前，Microsoft一直对VJ++保持模糊的态度，不愿意表明VJ++是否是一个纯正Java开发工具。更让Borland惊讶的是，Borland内部对于VJ++ Beta的测试表明VJ++编译出来的程序代码在某些方面居然比Delphi等原生的Windows开发工具执行得还快速。这意味着VJ++不但对于Java开发工具可能会有严重的影响，甚至对于一般的Windows开发工具都有可能造成威胁。不过Borland分析如果VJ++真的开始对Windows开发工具产生威胁，那么VB将会是受到影响最大的开发工具。但Borland仍然感到忧心，因为VJ++仍然可能对于Delphi和C++ Builder产生一定的影响，这是Borland不乐意见到的。当然这也加速了Borland研发 Latté的决心，因为已经不能再拖了。 记得当时我还和Borland在亚洲新加坡R&D总部的Mr. Inn Nam Yong谈过VJ＋+的表现以及对于VJ++可能产生影响的忧虑。Mr. Yong也说VJ++的表现令他们吃惊。看来Anders Hejlsberg在VJ++的编译器技术上下了苦功，其表现早已超过了当时一般的Java编译器技术，的确是令人刮目相看，更麻烦的是从VJ++的身上依稀可以看到Delphi的身影。 Borland的R&D已经了解了这个情形，Borland的编译器小组也在研究相关问题的技术。由此可见当时Borland已经如临大敌，开始准备相关的技术，并且已经掌握了初期的状况。 Microsoft VJ++在1996年11月终于正式推出了，全世界也都屏息以待，准备看着VJ++ 会产生多少的毁灭力量，而SUN更准备看看Microsoft是否会违反任何SUN和Microsoft 之间的Java协议。当然SUN是担心Microsoft想破坏Java的开发。VJ++在一开始果然获得了一些回响，毕竟这是Microsoft推出的Java工具，使用Microsoft开发工具的软件人员当然会考虑VJ＋+。同时VJ++也吸引了一些想使用Java语言、但是仍打算呆在 Windows平台的开发人员。 不过VJ++推出之后也很快受到了所有Java开发工具以及支持Java平台厂商的全面围剿。他们害怕Microsoft对Java市场的入侵，会让其他厂商再次无法生存。之后连SUN也开始领军围攻Microsoft，因为SUN除了害怕Microsoft会慢慢地主宰Java平台和标准之外，还发现Microsoft正在很有技巧地逐步破坏Java语言和标准，例如VJ++便提供了许多非标准的Java用法并且很明显地把VJ++绑死在Windows平台，破坏Java的"Write Once，Run Everywhere"的美梦。而且，Java开发人员如果大量使用VJ++，那么便再也离不开Windows平台。Microsoft计划通过提供一流的"类Java开发工具"来限制开发人员的自由选择权的企图是昭然若揭了。 由于SUN的带头批判，想使用Java的开发人员和企业很快地发现VJ++并不是标准的Java 开发工具，因此对于VJ++的热情很快消退了下来。而VJ++对于Java以及Windows开发工具的威胁也很快地解除了。VJ++对于Microsoft来说很可能是自DOS版的Microsoft Pascal之后第2次在开发工具的大失败。不过依我的观点来看，VJ++在本质上是一个优秀的产品，不论是编译器、Framework和集成开发环境都有高水平之作。VJ++之所以败阵下来实在是因为形势比人强，Java平台也是第一次不是由Microsoft所主宰的市场。在Java联军的合攻之下，即使是软件巨人也得回避三分。 因为第一次在Java出击就弄得灰头土脸，并且SUN摆明了不会允许Microsoft在Java平台成气候，使得Microsoft下定了和SUN正面开战、在Java市场上全面开火的决心，进而造成了SUN控告Microsoft违反Java合约的规定的结果，而Microsoft稍后则干脆把 Java支持从操作系统中移除。当然，这是Microsoft和SUN之间的Java平台之战，已超出本书讨论的范围，也许应该由Microsoft或是SUN的人来说明这整个过程。 虽然事后证明VJ++在Java开发工具是失败了，但是Anders Hejlsberg在VJ++中花费的心力却没有白费，因为VJ++的编译器技术以及Framework和集成开发环境的技术都在稍后融入Microsoft .NET计划的基础核心技术之中。例如C#的语言和Java很相像， C#的编译器技术想必也借重了许多当初VJ++优秀编译器的技术，因此C#编译器的最佳化结果也在一些方面胜过了现在许多原生Windows开发工具的编译器水准。Anders Hejlsberg的努力正激活了Java和.NET的正面决战。 IBM VisualAge For Java的推出 IBM在PC开发工具市场的表现一直令人摇头，因为其"玩玩便跑"的作风总是让人无法放心使用它的开发工具。但是也许是IBM的招牌太大，再加上它会免费向购买IBM机器或是软件的客户奉送IBM开发工具，因此也总是有人会去使用IBM的开发工具。我个人在受了IBM VisualAge For C/C++的教训之后，便对IBM的开发工具敬谢不敏了。 IBM当然不会放弃Java这个潜力无穷的市场，因为对于IBM来说，Java不光是语言和开发工具而已；更重要的是Java平台牵涉到IBM和SUN在庞大商机的硬件和大客户之间的竞争。IBM不光是要支持Java，更想从SUN手中取得Java的主控权，因此对于重要的Java 开发工具市场，IBM自是不会缺席。IBM很快采用了许多当初在VisualAge For C/C++ 中相当受欢迎的元素作为开发VisualAge For Java的基础。例如VisualAge For C/C++ 的项目管理功能、组件设计家等等。事实上使用过VisualAge For C/C++的读者会发现 VisualAge For Java非常的具有亲切感。不但所有的按钮都是采用圆形造型，甚至连激活时缓慢的感觉、整个集成开发环境温温吞吞的表现也非常相似。由于采用了 VisualAge For C/C++的部分观念和程序代码，再加上IBM拥有最丰富的资源，因此 VisualAge For Java进展得很快。 1997年9月，IBM终于推出了VisualAge For Java，开始直接和SUN、Symantec竞争。在IBM推出了VisualAge For Java之后，Borland注定成为最后一个推出重量级Java开发工具的厂商。不过IBM的竞争目标明显不是Symantec和Borland等纯粹以Java开发工具为目标的厂商，而是SUN和Microsoft。IBM在Java技术方面采取了数个平行的战略，希望能够在Java世界中取得龙头地位，因为这关系到IBM最大业务--硬件销售、服务提供以及IBM操作系统销售的收入。如果IBM能够在Java世界取得决定性的地位，那么就可以侵蚀SUN的市场，最不济的情形则是不希望客户因为想要使用Java技术而自然地想到SUN。至于另外一个锁定目标Microsoft，IBM则是打算通过Java日益扩大的声势来打击或是抑制之。 因此IBM一方面和SUN签订Java合约，取得Java使用的合法授权，另一方面又投入大量的研发资源开发自己的JDK版本以方便移植到IBM其他的专属平台，而且做得比SUN的 JDK还要稳定和有效率，随后让SUN和IBM之间一直有不和的争执。接着IBM推出了Java 开发工具，再次和SUN的Java Workshop竞争。不过从特性上来看，VisualAge For Java 锁定的客户群应该是IBM的客户、大型企业客户以及其他直接竞争对手的客户，例如 SUN的客户以及HP的客户。VisualAge For Java需要比较强劲的机器来执行，此外一开始的版本就非常注重团队开发的支持，不像其他的Java开发工具一开始都是注重在方便、实用的功能，稍后才逐渐强化团队开发的功能，这些差异都是IBM想争抢较大型客户的证明。这也可以从后来许多专业媒体和杂志在进行Java开发工具评比时 VisualAge For Java几乎都在团队开发功能方面获得了最高的评价得知。由于VisualAge For Java一开始锁定的客户群和Visual Café以及JBuilder锁定的客户群不同，因此在Java开发工具的竞争初期并没有发生严重的竞争冲突。但是随着Visual Café和 JBuilder逐渐往上仰攻企业市场，而VisualAge For Java为了扩大市场而开始降价进入一般Java大众市场之后，稍后的Java开发工具恶战也不可避免了。 第2阶段--Java集成开发环境的战争 Borland在初期以开发Java JIT编译器练兵之后，已经逐渐对于Java的技术有了掌握。在Java Workshop、VJ++和VisualAge For Java陆续推出之后，Borland知道再也不能够延迟JBuilder的推出时间了，否则就注定要退出Java开发工具的市场。因此Borland 对JBuilder的研发小组下了最后的通牒，一定要在1997年推出JBuilder。 JBuilder小组在竞争的第一阶段掌握了Java的JIT技术之后，立刻兵分多路展开了整个JBuilder的开发工作。虽然Java是一种全新的语言以及革命性的平台，但是开发工具总不外乎编译器、集成开发环境、数据库存取能力、Framework以及其他的工具和 Plug-In等。当时的Latté小组有许多成员是从以前的Borland C/C++转进来的，另外的一些成员则包括了Borland原本的软件研究成员、Paradox成员、Visual dbase成员以及从Borland外部找进来的新工程师。 在Borland开发JBuilder之时，由于Java尚没有完整的组件架构，也没有数据感知组件标准以方便地开发Java数据库应用程序，更加没有完整的Java可视化组件，因此 Borland决定先自行开发一套组件组以便让JBuilder拥有最好的组件开发能力。这刚好又是Borland擅长的技术，因为Borland要为Java开发一套Java Framework，这就是 JBCL(JavaBeans Component Library)的由来，而JBCL的架构稍后也成为SUN制定 JavaBean的基础技术。 当时负责JBCL架构的Architect是Joe Nunoll先生。这位帅哥原本属于Paradox小组，在Borland逐渐失利于桌上型数据库战场之后，便转到Latté小组专门负责设计Latté 的组件架构。 而JBCL的主要实现工程师则是当初设计和实现Borland C/C++ Framework-OWL的总工程师Carl Quinn。Carl Quinn在组件设计和Framework方面都有丰富的经验，OWL就技术而言也算是精品。因此在Borland C/C++产品线停止之后，Carl Quinn由C/C++转换到Java跑道是很自然的事情，毕竟C/C++和Java是很类似的。Carl拥有丰富的经验，由他来带领开发Latté的组件Framework是再适合不过了。 由于Carl在JBCL的努力和成果，稍后又负责了Borland的Java组件模型Baja的开发。之后Carl凭借着对于JBCL和设计Baja的经验，在SUN采用Baja做为JavaBean的核心基础技术之后便自然地受邀于JavaBean的开发小组。由于Borland在Java组件方面卓越的表现，因此也开启了SUN和Borland逐渐密切的合作。Borland虽然在Java方面投入的时程稍晚，但是却凭借着扎实的技术而慢慢迎头赶上。 Latté的Framework开发在Joe Nunoll和Carl Quinn的带领之下有了稳定的发展。事实上JBCL的表现一直是非常优秀的。当Latté随后正式推出时，JBCL也是让Latté得以脱颖而出的重要功能之一。Joe Nunoll和Carl Quinn的功劳可谓不小，而我钦佩的 Carl Quinn又再次在Java方面证明了他坚实的技术和在Framework方面丰富的设计和实现经验。 Java Framework虽然重要，但也只是整个完整开发工具的支柱之一。Latté要推出仍然需要编译器和集成开发环境的功能。在Java编译器方面，Borland和结束委托 Dr. Niklaus Worth研究小组开发Java JIT编译器之后，Latté开发小组便开始展开研究的工作。当时JIT编译器已经全面开战，而Borland在Latté尚未推出、还没有足够资源的情形下如果再介入JIT的战争，那么不但胜算不大，而且可能会严重影响Latté 的推出时程。因此Latté小组决定先专心开发一个编译品质良好，而且能够和Latté 完美搭配的Java编译器，而不再强求效率至上。 从现在的观点来看，当时Latté小组的决定是非常正确的。因为：第一，当时Borland 的确没有太多的子弹；第二，Latté的时程再也不能拖延；第三，也是最重要的是稍后SUN宣布了开发Hotspot编译器技术的计划，顿时之间所有Java JIT编译器的风头都被SUN抢走了。特别是在稍后SUN决定将Hotspot内建在JDK中之后，争夺Java JIT编译器不但变得没有意义，而且对于Java开发工具而言也没有什么附加价值了。因此在SUN 的Hotspot编译技术揭露之后，Symantec很快就在Java JIT编译器市场上销声匿迹了。 Latté小组确定了Java编译器的策略之后，立刻便接手Dr. Niklaus Worth研究小组的后续开发工作，同时开发Latté的编译器、Latté的Plug-In以整合Java编译器到 Latté的集成开发环境中，并且也进行Java编译器最佳化的研究工作。当时这个Java 编译器开发小组由Carl Fravel等人带领，同时也包括了Borland的编译器小组。Carl Fravel主要负责Latté的编译器以及编译器的Plug-In软件，此外他也参与了Latté 数据库方面的开发。当时Java在数据库存取方面仍然相当弱势，Borland为了加强Latté 这方面的功能，决定先借重Delphi在数据库方面的成绩，即通过JDBC标准接口封装 Delphi已经有的各种数据库驱动程序，让Latté能够立刻连接到最多的数据库，这就是后来JBuilder的DataGayteway。 除了Carl之外(嗯，Latté开发小组有两个Carl)，Sergio Cardoso也是Latté编译器最佳化的成员。Sergio原本是Borland C/C十+的开发者之一，专门研究C/C++最佳化的技术，他和Carl Quinn等人一样转移到Java的产品线。Sergio和Carl Fravel合作，负责打造Latté的核心引擎。在Latté上市之后，事实上每一版的JBuilder的编译器都有进步。就现在来说，在JBuilder 7/8中编译Java应用程序相当的快速。这说明 JBuilder和当初Borland C/C++一样，都是在初期版本快速地强化引擎、不断地提升速度。 当时的Latté并没有一个真正的总Architect，只有不同技术领域的Architect，例如 Joe Nunoll。因此Latté当时主要的舵手应该是产品经理以及Borland的Java资深研究员了。而产品经理以及Java资深研究员再和所有的各领域Architect讨论Latté的开发方向。因此在Latté的初期开发阶段，其模式就像罗马时期的合议制。 当时的Latte产品经理是Klaus Krull(K. K.)。这位仁兄长得又高又大，也是一位相当热心的人。K. K.原本是Paradox和dbase小组的成员，负责Paradox/dBase的产品线。在Latté小组成立之后K. K.立刻跳槽到Java产品线来。事实上许多Paradox/dBase 的工程师也都希望转换到Java产品来，因此当时在Borland内部掀起了很大的风浪，也造成了许多人离职。这段故事在稍后的dbase相关章节中将详细说明。 K. K.加入了Latté小组之后，便积极地带领Latté小组往前冲。也许是因为K.K.在 Paradox和dBase时表现得并不好，因此想借着Latté证明自己的实力。不过K. K.人也许很好，可是管理方面似乎仍然不甚灵光，Latté初期的进度仍然稍嫌缓慢。在IBM VisualAge For Java于1997年推出之后，Borland高层下令K. K.绝对不可以再度延迟进度，一定也要在1997年推出第一个Latté版本。好在当时Delphi 3大获全胜，而 K. K.又是当时Delphi产品经理Ben Riga的好哥们，因此由Delphi转入Latté的资源也就源源不绝，让Latté的进度慢慢地赶上了。 至于当时Latté架构的主要人物并不是稍后众人皆知的Blake Stone，因为Blake Stone 是在Latté推出之后才加入Borland的。Latté初期的架构负责人应该是Steve Shaughnessy。 Steve是Borland的资深研究人员，也是当初Borland最早投入Java技术研究领域的人物之一。不过资深研究人员的缺点之一是喜欢不断地想象以及研究软件技术，但是对于产品进度的掌握却不是他们的专长，也不是他们最关心的事情。这就是为什么Latté 一开始的开发进度非常缓慢的原因。直到最后K. K.加入并且面临了Borland高层和市场巨大的压力之后才匆匆地集中所有的资源和时间想要追上进度。 当Latté小组开发JBuilder的第一个版本时，就想学习使用Delphi成功的Open Tools API特性，为JBuilder定义完整而且极具弹性的开放式集成开发环境。不过由于当时 Delphi的Open Tools API仍然没有大量的采用接口程序设计的架构，考虑到Java拥有定义良好的接口机制，无法完全采用Delphi的Open Tools API的设计，所以一开始 JBuilder集成开发环境的Add-ins功能开发得很缓慢。当时负责JBuilder集成开发环境中Add-ins功能的工程师除了Carl Fravel之外，另外一位主要的工程师则是Greg Cole。 当Carl Fravel和Greg Cole了解到无法直接借用Delphi的Open Tools API来设计JBuilder 的Add-ins架构之后，就决定开始研发JBuilder本身的集成开发环境开放架构，并且直接使用接口程序设计的机制来设计JBuilder的开放架构，这是和当时的Delphi不一样的地方。而一直要到Danny Thorpe为Object Pascal程序语言加入了接口机制之后， Delphi的Open Tools API才展开了第2波的大改版，使用接口机制来重新设计，也就是后来Delphi著名的OTA架构(Open Tools Architecture)。 1997年11月，Latté终于完成并且推出市场。正式的产品名称被定为Open JBuilder，这是为了强调Borland的Java开发工具就像Java本身一样是使用开放的架构。 在Open JBuilder 1.0推出之后，Java开发工具市场总算是竞争者齐聚一堂了，每一家厂商终于一一地使出了真本领来竞逐Java开发工具的市场龙头。Open JBuilder 1.0 推出之后不久，几乎所有的信息媒体以及Java的专业杂志都进行了Java开发工具的评比，想要比较所有Java开发工具的优/缺点，并且让Java的使用者了解当时市场的老大Visual Café是否能够面对新兴势力的挑战，保住市场第一的地位。 当时大多数杂志评比的目标包括了Symantec的Visual Café、SUN的Java Workshop、 IBM的VisualAge For Java以及Borland的Open JBuilder 1.0。对于Symantec来说，第一次的Java开发工具大会战是处于以逸待劳的情势，而且Visual Café也是4个Java 开发工具中唯一完全使用C/C++语言撰写的，因此面对当时Java编译器还不够好、JVM 品质也未若今日精良的情形下，Visual Café的执行速度占了非常明显的优势，在功能方面当然也胜出其他竞争对手一截。 Symantec的Visual Café唯一的缺点就是在Java程序代码中加入了开发工具特有的程序代码卷标，造成使用Visual Café撰写的Java程序代码不易使用在其他开发工具中的后果。而且Visual Café在Render Java图形使用者接口时仍然拥有不十分精确的问题。 当时对SUN的Java Workshop的评比是比较保守的。毕竟Java Workshop是Java正宗厂商SUN推出的产品。虽然它不论在功能、执行效率方面都比不上竞争对手，而且小问题一大堆，但是为了给SUN面子，媒体仍然没有给予太多的苛责。甚至有一些媒体还称赞SUN有勇气开发一个完全使用Java语言撰写的Java开发工具，向全世界证明Java 是能够用来开发大型应用程序的。不过虽然媒体和杂志很给SUN面子，但Java Workshop 终究逃不过市场的考验，从此慢慢地退出了Java开发工具的市场。 在当时的评比中IBM的VisualAge For Java虽然是执行最为缓慢的Java开发工具，但是在高阶功能方面的表现却是遥遥领先所有的竞争对手。VisualAge For Java的团队开发功能、项目管理功能以及可视化设计家都大幅超越了其他的Java开发工具。不过 VisualAge For Java使用了专属的格式，因此其程序代码不容易使用在其他的工具中，而且VisualAge For Java的项目在进入了Repository之后也发生过整个Repository 毁损的情形，因此当时VisualAge For Java在易用性方面的分数是比不上其他竞争对手的。 对于Borland的Open JBuilder 1.0来说，这个最晚进入竞争市场的工具在第1次的集体评比中最后的结果不如人意。原本Java的使用者以及专业媒体对于Borland的产品有着高度的期待。因为以Borland一向精于开发工具，而且是最后才推出Java开发工具的情形来推断，大多数人都认为Open JBuilder应该是准备最充分的，但是评比之后的结果却不是如此。 首先Open JBuilder并不是纯粹使用Java撰写的开发工具，而是混合了Java和Delphi 的程序代码。不过最后的执行效率不但比不上Visual Café，也不比纯粹的Java Workshop快上多少。此外Open JBuilder在功能方面比不上Visual Café，在可视化设计家和高阶功能方面又不是VisualAge For Java的对手。在比上不足，比下只有险胜的情形下Open JBuilder让当时许多人大失所望，当然也包括了我在内。因此在大多数的评比中，Open JBuilder只得到中等的评价。当然这样的结果也反映在Open JBuilder的市场表现之上。 Hotspot编译技术是个笑话吗？ 1997年市场上逐渐出现愈来愈多的Java开发工具，愈来愈多的人开始尝试使用Java，却也有愈来愈多的人抱怨Java的执行效率。当时的PC不像今日动不动就拥有1GHz的执行效率以及512MB RAM的内存，以当时的机器来执行Java是很痛苦的事情。还记得当时我还没有动力足够的机器来跑Open JBuilder，每一次执行Open JBuilder时就觉得受不了。当时我还开玩笑地说，机器从执行Open JBuilder到进入Open JBuilder的集成开发环境这段时间，早就够我使用Delphi写完一支程序了。造成Java执行效率缓慢的主要原因当然是Java编译器以及JVM的品质不够精良了。 为了急于让信息界接受Java成为标准，SUN必须想办法克服这个问题。虽然克服Java 执行缓慢的现象是当时几乎所有支持Java软件厂商都想解决的事情，但Java的正宗厂商SUN是责无旁贷的。也是因为Java执行效率的缓慢，当时也兴起了许多小的软件厂商开发各种技术和编译器来改善或是解决Java的这个致命缺点。很快SUN找到了一家小软件公司，这家公司以开发出"Adaptive Compiling"技术来加快JVM执行效率、以及使用类似的技术来改善Java编译器的品质而闻名。SUN在了解到这些杰出的技术之后便立刻决定购买这家公司，并且根据他们的技术来实现SUN的下一代Java编译器以及JVM，这就是稍后SUN HotSpot技术的由来。 SUN投入新的Java编译技术之后不久，就有了初步的结果。根据这个新的技术编译出来的Java ByteCode以及新的JVM的执行效率果然比以前进步了许多。这让SUN更有信心，便立刻向世界公告了这个新的技术，并且命名为HotSpot。SUN宣称最后推出的Java 编译器和JVM将提供类似C++的执行效率。 在SUN公布了HotSpot技术之后，立刻引起了全世界Java使用者的狂热。人们认为一旦 SUN推出这个技术，Java将可望克服最后一个缺点，从而一统天下。与此同时，这也引起了信息业界非常大的讨论和争议。特别是C/C++社群的人认为这根本是不可能的，虽然"Adaptive Compiling"非常的有创意，但是要和已经存在数年的C++最佳化编译器比起来，Java的ByteCode是不可能超越C++的。但是从SUN在其时公布的一些HotSpot 编译数字来看，"Adaptive Compiling"是非常有希望的，因为它改善的幅度实在是很大。因此全球相关的人员都在屏息以待，准备看看SUN最后的成果。 在SUN第1次公布HotSpot的推出时程之后，果然让所有Java的使用者都引颈期盼，恨不得SUN立刻推出这个技术，解除大众执行Java的痛苦。不过随着时间不断的接近， SUN在最后关头又宣布因为研发不及因此要延迟HotSpot推出的时程。软件研发的工作延后在软件界见怪不怪，当时也没有引起太多的争议，不但让SUN争取到了更多的时间，也顺利地延后了推出的时程。 不过在SUN宣布的第2次推出时程到期时，SUN仍然无法推出HotSpot技术。很快的SUN 不得不再次宣告要延后HotSpot的时程。就在这样SUN不断跳票的戏码重复上演的情形下，终于开始有人笑称HotSpot根本是一个骗局，SUN根本无法推出接近C++执行效率的Java编译技术。 到了1999年左右，SUN自知再也无法推拖HotSpot推出的时程了。因此在当年8月，当时HotSpot研发小组的领导人(一位博士，但是我已经忘记了他的名字)在BorCon上进行Keynote Speech，正式向参加BorCon的人介绍HotSpot技术并且在现场展示了HotSpot 的研发成果。虽然一切看起来都很棒，但是当现场的听众直接询问到底HotSpot技术是否能够超越C++的执行效率时，这位博士却没有正面回答，只解释说在一些应用中 HotSpot的确可以提供超越C++的执行效率。我听了之后心中大概就已经知道HotSpot 最终的结果了。 果然在HotSpot被迫推出市场之后，大家很快地了解到HotSpot和C++的执行效率相比终究是还有一段距离，根本无法超越C++的表现。这造成了当初一些热切期待的C/C++ 程序员回到C/C++语言的市场，并没有转换到Java市场。这也是为什么后来C/C++市场虽然受到了Java的影响，但是仍然有大量的使用者和市场，并没有像当时许多人预测的那样将会有大量的C/C++程序员进入Java市场，终究还是因为Java无法完全取代 C/C++语言来完成一些工作。而SUN呢？为了转移大家对于HotSpot的失望而开始把研发重点转到Internet/Intranet、EJB组件模型和Java Mobile系统方面的研发。轰动一时的HotSpot热潮也逐渐淡去。 现在SUN再也不怎么提起HotSpot编译器了，只是在每一个新版本的JDK中不断持续的改善HotSpot的编译品质。想起当初SUN对HotSpot不可一世的吹嘘最是令人感叹。不过HotSpot也不是一无是处，的确是精进了许多Java ByteCode的产生品质以及JVM的执行效率，只是没有达到当初SUN夸口逼近或是超越C语言编译器品质的程度。在目前状况下，HotSpot能够让Java的编译品质在伺服端的效率有着显著的提升，提供非常不错的执行效率。但是在客户端，尤其是牵涉到图形使用者接口Render方面的应用时，仍然是相当缓慢的。 就Borland本身使用Java的情形来说，Borland使用Java开发的VisiBroker For Java 的执行效率已经相当接近VisiBroker For C/C++的执行效率。因此如果再搭配使用品质良好的JVM，那么根据Borland内部的测试数据显示，VisiBroker For Java甚至在一些特定的应用中超越了VisiBroker For C/C++。 HotSpot在纷纷扰扰的这么多年之后到底是不是一些人讥笑的"笑话科技"呢？不同的人到现在可能还是有不同的答案吧。 Borland的困境和选择 Open JBuilder虽然赶在1997年最末的一班车推出，但在市场上的反映并不如预期的好。当然这是有许多原因的。首先是Open JBuilder太晚推出，初期的Java市场早已被其他的Java开发工具，特别是Visual Café所占领；第二是Open JBuilder急着推出市场，因此在和其他Java开发工具竞争时并没有什么特别突出的功能、明显的优势，竞争力当然不够；第三是Open JBuilder于一开始就混合地使用了Delphi和Java程序代码，因此Open JBuilder激活以及窗体设计家的反应都很缓慢，不像Visual Café 那种以纯C/C++程序代码撰写的Java开发工具反应迅速，从而给许多程序员造成了不良的印象。IBM的VisualAge For Java虽然也很迟缓，但在高阶的团队开发方面却支持得很好，而且通常会使用团队开发功能的使用者大都是属于企业或是大型用户，因此使用的机器配备也很好，对于VisualAge For Java的缓慢反应也还能够接受。 Open JBuilder的表现不如预期，这让Borland很着急，因为其无法承受失去Java开发工具市场的损失。因此在Borland的Java开发工具研发小组中开始有了一些讨论，那就是如何让Open JBuilder能够后来居上，取得胜利的果实。针对Open JBuilder的失败原因，Open JBuilder的开发人员开始反思是否也应该像Visual Café一样使用 Delphi重新打造Open JBuilder，让Open JBuilder的执行反应加快到使用者能够接受的地步，因为在当时Borland实在已经无法再加快Java的执行速度。此外使用Delphi 开发Open JBuilder的窗体设计家也可以避免许多JDK的臭虫，不会因SUN开发或是改善JDK的时程而影响到Open JBuilder的开发周期。 这个想法在Open JBuilder的内部引起了很大的争议。使用Delphi重写Open JBuilder 的集成开发环境可以拥有许多短期的效益而且产品马上会有明显的改善，可以拥有和其他竞争对手一搏的本钱。不过反对的人则认为使用原生开发工具开发Java的工具是走回头路。这些人认为Java有朝一日一定会开发到成熟的阶段，到时Open JBuilder 就会拥有最后的胜利，现在只是一时的挫折，没有必要灰心。 对于Borland来说，如何继续Open JBuilder是一个困难的抉择，因为当时Borland急需收入的挹注，而Open JBuilder的研发费用惊人，光靠Delphi力撑实在是很辛苦。不过如果再回到使用Delphi开发，那么可能又会失去未来的机会，这到底应该如何决定呢？ Java天才的加入 这一切的答案在Open JBuilder的新产品架构领导人Blake Stone加入后才逐渐明朗。 Blake Stone原本是DSW Systems Corporation公司的技术主管，而DSW公司一向和Borland 互动良好，许多DSW公司的人都曾在Borland的Conference(BorCon)中负责技术讲座。 Blake Stone先生也在1997年的BorCon中负责了一个讲座。也许是Blake Stone和Borland 在这次的BorCon中合作愉快，Borland也很赏识Blake Stone的技术和才华，因此在BorCon 结束之后不久，Borland便和Blake Stone接触，看看Blake是否有意愿加入Borland的 Java研发小组。也许是天意吧，在Borland失去了Anders这个天才之后，老天又给了 Borland一个弥补软件天才的机会。 在Borland和Blake接触之后，Blake不但对于Java未来的潜力看好，而且因为Blake也曾使用Delphi，对于Borland研发开发工具的能力相当有信心。更凑巧的是由于Open JBuilder 1.0的不尽人意，因此此时刚好有一个Open JBuilder的Architect离职，让Blake立刻有了适当的职位。没有多久Blake便答应进入Borland作为JBuilder的 Architect，目的是带领JBuilder成为最成功的Java开发工具。由于Blake惊人的天分，因此很快就成为JBuilder的主要Architect以及技术的主领导者，JBuilder未来开发的Java技术都由Blake负责研究和研发的工作。 Blake进入JBuilder开发小组之后，面临的第一个挑战便是如何改造Open JBuilder，让它执行得更为顺利，并且能够在竞争群中脱颖而出。当然Blake必须做的第一个抉择就是Open JBuilder到底该走向纯Java的开发工具或是改成原生的Windows Java开发工具。Blake并没有迟疑多久，便决定把JBuilder带向纯Java的开发工具，使用Java 语言本身来打造整个JBuilder。Blake做了如此的决定是有许多原因的。首先是Blake 希望通过使用Java语言开发JBuilder本身来让Borland的工程师彻底掌握Java的技术，也希望通过这样的开发来证明Java的实用性。就像Delphi本身就是使用Object Pascal 和Delphi研发、Borland通过Object Pascal证明了Delphi的实用性和可靠性一样， Blake也希望使用JBuilder来证明Java语言的可用性。 第2点是因为打造纯Java开发工具可以让JBuilder通过Java跨平台的特性把JBuilder 推向其他所有支持Java的平台%8

转载于:https://www.cnblogs.com/chaunqi/archive/2011/05/25/tt123.html