四
四库全书
Unregistered / Unconfirmed
GUEST, unregistred user!
终于在网上找到了一位志同道合的网友,使大家能够看到最精彩的第五章的一部分
希望更多的网友加入到录入的行列中来
第八章请参见:
http://www.delphibbs.com/delphibbs/dispq.asp?lid=2135073
http://www.delphibbs.com/delphibbs/dispq.asp?lid=2149792
------------------
Borland 传奇
作者：李维
第五章：逆转的奇迹——Borland JBuilder 的战斗发
展史
录入：windknight
·Java 开发工具初期的争战
·Borland 的Java 艰辛奋斗
·第一阶段－－Java JIT 编译器的战争
·Microsoft VJ++的威胁
·IBM Visualage For Java 的推出
·Java 集成开发环境的战争
·Hotspot 编译技术是个笑话吗？
·Borland 的困境和选择
·Java 天才的加入
·
·
·
·
·
“没有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 并没
有那么顺利。1995 年，当Java 开始起飞时，Borland 并没有预料到Java 成长的速度会如此
之快。Borland 一开始只是把Java 当成C/C++的延伸，因此只在Borland C/C++ 5.0 中加入了
支持Java 的Plug-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 Cafe.
Symantec 几乎是第一个接入Java 开发工具的软件公司，又利用了Symantec C/C++的
基础，因此在1995 年，当Java 获得愈来愈多人主义之后，Symantec 也准备好了他的第一个
Java 开发工具－－Visual Cafe。1996 年10 月，Symantec 赶在JDK1.1 之前正式推出了Visual
Cafe。虽然当时与许多人批评Symantec 为什么不等到JDK1.1 之后再推出，以支持最新的
JDK 标准（因为当时的JDK1.0x 版本有许多的问题），不过这些批评并没有妨碍Visual Cafe
的成功。
由于当时许多软件人员急于投入Java 的学习行列，因此当Symantec 推出了Visual Cafe
之后，立刻在市场获得了极大的成功。特别是在Java 学习市场和教育市场，Visual Cafe 几
乎是一席卷市场的姿势迅速占据了Java 开发工具第一名的地位，成为炙手可热的产品，而
Symantec 公司也一扫在C/C++开发工具被挫败的怨气，再次成为开发工具市场的领导厂商。
由于当时Microsoft 对于Java 采取敌视的态度，因此几乎不可能推出Java 开发工具，而
Borland 也正陷于C/C++的苦战之中，尚未察觉到Java 的潜力。至于另外一个死对头Watecom
则已经被Sybase 并购，无法在开发工具市场再成气候。这对于Symantec 来说简直是天赐良
机，一个可以独打Java 开发工具市场的绝佳机会。剩下唯一的威胁是SUN 要推出的Java
开发工具。但是Symantec 已经抢得市场先机，而且已经成为领先者，只要好好的把握，就
能够以逸待劳和SUN 对战。在这个Java 开发工具萌芽的阶段，Symantec 似乎是占了绝对的
优势，不过很可惜的是接下来Symantec 也接连犯了几个错误，逐渐失去了取得的优势。
首先是当Visual Cafe 推出之后，Eugene Wang 便离开了Symantec 自己开公司做生意去
了。这对于Visual Cafe 有着相当大的影响，因为Symantec 靠着Eugene Wang 的技术能力和
眼光，才能够和Microsoft，Borland 和Watcom 在C/C++开发工具市场对抗：Eugene Wang
又独具慧眼打造了第一个Java 开发工具Visual Cafe。Symantec 应该在Visual Cafe 获得初期
的胜利之后再次借重Eugene Wang 的功力继续攻城掠地，但是Symantec 居然让Eugene Wang
离开，立刻少了开发工具掌舵的大将。
第二个错误是Symantec 当初为了尽快推出Visual Cafe 以抢占市场先机，因此集成开发
环境是使用C/C++语言撰写的。这造成了数项缺点，其一是由于使用了C/C++来撰写可视化
窗体设计家（Visual Form Designer），因此程序员在设计时看到的可视化效果和真正Java 程
序执行时的效果是有一些差异的；其二是为了维护Java 的控制组件程序代码和以C/C++撰
写的可视化窗体设计家保持同步的状态，在可视化状体设计家产生的原始程序代码中内嵌了
一些Visual Cafe 控制卷标（Control Tag）。这些控制卷标并不是Java 的程序代码，只是为了
可视化窗体设计家使用。如果程序员不小心修改或时删除了这些控制卷标，就会造成Visual
Cafe 的可视化窗体设计家的失效。这是非常严重的缺点，Symantec 应该在Visual Cafe1。0
之后立刻改善这些问题，然而Symantec 似乎一直无法有效地加以改善。当然，问题的根源
在于Visual Cafe 的集成开发环境是使用C/C++语言撰写的，要完全改善这个问题，Symantec
必须使用Java 语言重新改写集成开发环境，这正是Borland 后来采取的策略。不过使用Java
撰写集成开发环境也是非常冒险的行动，Borland 后来因此付出了沉重的代价。Symantec 之
所以没有如此做，大概也是因为当时的Java 并没有成熟到可以如此做的地步。不过SUN 显
然不这么认为，其对Java 信心百倍，不久就推出了SUN 的Java 开发工具，Java Workshop。
当Java 成功的掳获了开发者得心之后，对于Java 开发工具的要求便于日俱增。虽然
Symantec 已经推出了Visual Cafe，但是许多人仍然希望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
之后，才发现它不但执行缓慢的像乌龟一样，而且问题多多，和一般的PC 开发工具水准比
起来简直是差了十万八千里。看来Java Workshop 只是和使用在昂贵的SUN 工作站计算机
上，而在当时大多数人使用的PC 上则根本跑不动，除非使用有异于常人的耐性。
Java Workshop 雷声大雨点小，不久之后就人气溃散了。许多原来对Java 有信心的人在
用了Java Workshop 之后，也开始质疑Java 是否适合是用来开发复杂的应用程序？是不是只
适合用来专习Applet？是不是只适合使用在SUN 的工作站和计算机之上？虽然之后SUN 仍
然很努力的推出了Java Workshop2.X 的版本，希望一洗Java Workshop 1.X 的恶名，但是仍
然无法挽回Java 开发人员的信心。至于其他仍然对Java 有兴趣的人则转而使用Symantec
的Visual Cafe，让Visual Cafe 进一步的扩大了市场占有率，也让Symantec 吃了一颗定心丸。
当然也有许多Borland 的支持者开始强烈的期望和要求Borland 能够推出最好的Java 开发工
具。
SUN 在Java 开发工具市场大溃败之后，才了解到PC 开发工具市场和Solaris 开发工具
市场不一样。在Solaris 上SUN 是一家独大，但是在PC 市场尚可是百家争鸣，竞争对手一
个比一个强悍。SUN 不了解PC 开发工具市场的特性，一味靠着Java 正宗的招牌就可以通
行无阻却是大错特错，并且在当时被Micorsoft 讥笑不懂得开发软件，这也是因为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 Cafe 早已成功的上市，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 开发工具的内部研发名称便是Latte。一开始Latte 小组的研
发资源并不够多，因为当时的Borland 是在风雨飘摇之中，无法注入足够的资源到Latte 小
组。因此在Latte 开始开发的初期进展得并不顺利，进度很缓慢。一直到了Borland 靠Delphi
浴火重生之后，Latte 小组才有了足够资源，研发的进度才开始加速。不过与竞争对手们比
起来，Borland 在Java 方面的确是相当落后的，几乎是跑在最后的参赛者。不过幸运的是Java
开发工具之战似乎是一场漫长的马拉松比赛，除了一开始的表现之外，更重要的是比谁能构
成的比较久。事实上看Borland 如何在Java 竞赛场上反败为胜，一一打败强者，进而成为
Java 开发工具王者的过程是相当精彩的，而JBuilder 小组使用的竞争策略更值得我们玩味和
学习。
依我个人眼光来看，在Borland 开发Java 开发工具的过程中经历了数个不同的阶段，每
一个阶段都有着非常激烈的竞争，有着成功者和失败者。只是有的失败者仍然坚持竞争下去，
有的却随风消散。JBuilder 最终能够成为王者，除了是因为愈挫愈勇，Borland 并没有退出
Java 市场之外，还在于Borland 在开发JBuilder 3 是下了一个关键性的决定，以及在JBuilder
3 之后每一个版本都有明确的目标，终于在JBulider 4之后慢慢成为市场第一的领导者。当
然这长达数年的征战过程是非常艰辛的，不过这段历程正是整个Java 开发工具逐鹿中原的
写照史
第一阶段－－Java JIT 编译器的战争
Borland 也许不是最晚开始研发Java 技术的厂商，但是明显是落后于其他竞争对手则是
不正的事实。Borland 在Latte 万事尚未具备的情形下，展开Java 竞赛的第一步便是从Borland
传统的拿手绝活开始，那就是从Java JIT 编译器开始出发。不过由于Borland 当时对于Java
技术尚未拥有良好的掌握，因此一开始是和Pascal 的祖师爷Dr.Niklaus Worth 合作，有
Dr.Niklaus Worth 以及他的学生们为Borland 研发Java JIT 编译器，而Borland 本身的Latte
小组则平行的开发Latte 其他的功能。由于当时Java 已经逐渐在校园流行，而且吸引了许多
学术研究的兴趣，Dr.Niklaus Worth 以及他的学生们很早便开始投入Java 相关的研究。因此
当Borland 找上门之后，自然便一拍即合。Borland 缩短了开发时程，而Dr.Niklaus Worth 研
究小组则乐得有人赞助研发费用。
Dr.Niklaus Worth 研究小组的第一个作品就是在1997 年初左右推出的Java JIT 编译器，
这个由Dr.Niklaus Worth 研究小组研发的JIT 编译器可以让编译后的Java Btyecode 执行速度
比当时的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 的处女作JavaJIT 编译器一炮而红，立刻吸引了当时浏览器霸主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 在全世界将立刻拥
有数百万的Latte 潜在使用者，对于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 编译器的竞赛，以求全速催生Latte。
当然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 Cafe 中，成为一项吸引人的功能。不过很快这个功能却引起了许多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 Cafe 在JBuilder，Visual Age For Java 陆续推出之后市场占
有率已经慢慢的被瓜分，现在有得再次面对Microsoft 的竞争，昔日Symantec C/C++失败的
阴影又缠上了心头。而Microsoft 的死对头IBM 更是在Visualage For C/C++，Visualage For
BASIC 连番失败之后，好不容易推出了Visualage For Java，准备在Java 开发工具市场打一
场好球赛，没有想到现在Micorsoft 又来搅局。
对于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 开发工具都有可能造成威胁，那么VB 将会使受到影响最大的开发工具。但
Borland 仍然感到忧心，因为VJ++仍然可能对于Delphi 和C++Builder 产生一定的影响，这
是Borland 不乐意看到的。当然这也加速了Borland 研发Latte 的决心，因为已经不能再拖了。
记得我当时还和Borland 在亚洲新加坡R&D总部的Mr.Inn Nam Yong 谈过VJ++的表现
以及对于VJ++可能产生影响的忧虑。Mr.Young 也说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 开
发工具的威胁也很快的接触了。V++对于Microsoft 来说很可能是自DOS 版的Microsoft
Pascal 之后的地而此在开发工具的大失败。不过依我的观点来看，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#编译
器的最佳化结果也在一些方面胜过了现在许多原生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 Cafe 以及JBuilder 锁定的客户群不同，因此在Java 开发工具竞争初期并没有发生严
重的竞争冲突。但是随着Visual Cafe和JBuilder 逐渐往上仰攻企业市场，而Visualage For Java
为了扩大市场而开始降价进入一般Java 大众市场之后，稍后的Java 开发工具恶战也不可避
免了。
第二阶段――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 等。当
时的Latte 小组有许多成员是从以前的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 逐渐势力于桌上型数据库战场之后，便转到Latte 小组专门负责设计Latte 的组建
架构。
而JBCL 的主要实现工程师则是当初设计和实现Borland C/C++ Framework－OWL 的总
工程师Carl Quinn。Carl Quinn 在组件设计和Framework 方面都有丰富的经验，OWL 就技
术而言也算是精品。因此在Borland C/C++产品线停止以后，Carl Quinn 由C/C++转换到Java
跑道是很自然的事情，毕竟C/C++和Java 是很类似的。Carl 拥有丰富的经验，由他来带领
开发Latte 的组件Framework 是再合适不过了。
由于Carl 在JBCL 的努力和成果，稍后又负责了Borland 的Java 组件模型Baja 的开发。
之后Carl 凭借这对于JBCL 和设计Baja 的经验，在SUN 采用Baja 作为JavaBEAn 的核心基
础技术之后便自然的受邀于JavaBEAn 的开发小组。由于Borland 在Java 组件方面卓越的表
现，因此也开启了SUN 和Borland 逐渐密切的合作。Borland 虽然在Java 方面投入的时程稍
晚，但是却凭借着扎实的技术而慢慢迎头赶上。
Latte 的Framework 开发在Joe Nunoll 和Carl Quinn 的带领之下有了稳定的发展。事实
上JBCL 的表现一直是非常优秀的。当Latte 随后正式推出时，JBCL 也是让Latte 得以脱颖
而出的重要功能之一。Joe Nunoll 和Carl Quinn 的功劳可谓不小，而我钦佩的Carl Quinn 又
再次在Java 方面证明了他坚实的技术和在Framework 方面丰富的设计和实现经验。
Java Framework 虽然重要，但也只是整个完整开发工具的支柱之一。Latte 要推出仍然
需要编译器和集成开发环境的功能。在Java 编译器方面，Borland 和结束委托Dr.Niklaus
Worth 研究小组开发Java JIT 编译器之后，Latte 开发小组便开始展开研究的工作。当时JIT
编译器已经全面开战，而Borland 在Latte 尚未推出，还没有足够资源的情形下如果再介入
JIT 的战争，那么不但胜算不大，而且可能会严重影响Latte 的推出时程。因此Latte 小组决
定先转行开发一个编译品质良好，而且能够和Latte 完美搭配的Java 编译器，而不再强求效
率之上。
从现在的观点来看，当时Latte 小组的决定是非常正确的。因为：第一.当时Borland 的
确没有太多的子弹；第二，Latte 的时程再也不能拖延；第三，也是最重要的是稍后SUN 宣
布了开发Hotspot 编译器技术的计划，顿时所有Java JIT 编译器的风头都被SUN 抢走了。特
贝是在稍后SUN 决定将Hotspot 内建在JDK 中之后，争夺Java JIT 编译器不但变得没有意
义，而且对于Java 开发工具而言也没有什么附加价值了。因此在SUN 的Hotspot 编译技术
揭露之后，Symantec 很快就在Java JIT 编译器市场上销声匿迹了。
Latte 小组确定了Java 编译器的策略之后，立刻便接手Dr.Niklaus Worth 研究小组的后
续开发工作，同时开发Latte 的编译器，Latte 的Plug-in 以整合Java 编译器到Latte 的集成
开发环境中，并且也进行Java 编译器最优化的研究工作。当时按各Java 编译器开发小组由
Carl Fravel 等仍带领，同时也包括了Borland 的编译器小组。Carl Fravel 主要负责Latte 的编
译器以及编译器的Plug-in 软件软件，此外他也参于了Latte 数据库方面的开发。当时Java
数据库存取方面仍然相当弱势，Borland 为了加强Latte 这方面的功能，决定先借重Delphi
在数据库方面的成绩，即通过JDBC 标准接口粉状Delphi 已经有的各种数据库驱动程序，
让Latte 能够立刻联接到最多的数据库，这就是后来JBuilder 的DataGateway。
除了Carl 之外（嗯，Latte 开发小组里有两个Carl），Sergio Cardoso 也是Latte 编译器最
佳化的成员。Sergio 原本是Borland C/C++的开发者之一，专门研究C/C++最佳化的技术，
他和Carl Quinn 等人一样转移到Java 的产品线。Sergio 和Carl Fravel 合作，负责打造Latte
的核心引擎。在Latte 上市之后，事实上每一版的JBuilder 的编译器都有进步。就现在来说，
在JBuilder 7／8 中编译Java 应用程序相当的快速。这说明JBuilder 和当初Borland C/C++一
样，都是在初期版本快速的强化引擎，不断的提升速度。
当时的Latte 并没有一个真正的总Architect，只有不同技术领域的Architect，例如Joe
Nunoll。因此Latte 当时主要的舵手应该是产品经理以及Borland 的Java 资深研究员了。而
产品经理以及Java 资深研究员再和所有的各领域Architect 讨论Latte 的开发方向。因此在
Latte 的初期开发阶段，其模式就象罗马时期的和一致。
当时的Latte 产品经理是Klaus Krull（K.K.）。这位仁兄长的又高又大，也是一位相当热
心的人。K.K.原本是Paradox 和dBase 小组的成员，负责Paradox/dBase 的产品线。在Latte
小组成立之后K.K.立刻跳槽到Java 产品线来。事实上许多Paradox/dBase 的工程师也都希望
转换到Java 产品来，因此当时在Borland 内部掀起了很大的风浪，也造成了许多人离职。这
段故事在稍后的dBase 相关章节中将详细说明。
K.K.加入了Latte 小组之后，便积极的带领Latte 小组往前冲。或许是因为K.K.在Paradox
和dBase 时表现得并不好，因此想借着Latte 证明自己的实力。不过K.K.人也许很好，可是
管理方面似乎仍然不甚灵光，Latte 初期的进度仍然稍嫌缓慢。在IBM Visualage For Java 于
1997 年推出之后，Borland 高层下令K.K.绝对不可以再度延迟进度，一定也要在1997 年推
出第一个Latte 版本。好在当时Delphi3 大获全胜，而K.K.又是当时Delphi产品经理Ben Riga
的好哥们，因此由Delphi 转入Latte 的资源也就源源不绝，让Latte 的进度慢慢的赶上了。
至于当时Latte 架构的主要任务并不是稍后众人皆知的Blake Stone，因为Blake Stone
是在Latte 推出之后才加入Borland 的。Latte 初期的架构负责人是Steve Shaughnessy。
Steve 是Borland 的自身研究人员，也是当初Borland 最早投入Java 技术研究领域的人
物之一。不过自身研究人员的缺点之一是喜欢不断的想象以及研究软件技术，但是对于产品
进度的掌握却不是他们的专长，也不是他们关心的事情。这就是为什么Latte 一开始的开发
进度非常缓慢的原因。直到最后K.K.加入并且面临了Borland 高层和市场巨大的压力之后才
匆匆的集中所有的资源和时间想要追上进度。
当Latte 小组开发JBuilder 的第一个版本时，就象学习使用Delphi成功的Open Tools API
特性，为JBuilder 定义完整而且极其弹性的开放式集成开发环境。不过由于当时Delphi 的
Open Tools API 仍然没有大量的采用接口程序设计的架构，考虑到Java 拥有定义良好的接口
机制，无法完全采用Delphi 的Open Tools API 的设计，所以一开始JBuilder 集成开发环境的
Add-ins 功能开发环境中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 月，Latte 终于完成并且推出市场。正式的产品名称被定义为Open JBuilder，
这是为了强调Borland 的Java 开发工具就像Java 本身一样是使用开放的架构。
在Open JBuilder 1.0 推出之后，Java 开发工具市场总算是竞争者齐聚一堂了，每一家厂
商终于一一的使出了真本领来竞逐Java 开发工具的市场龙头。Open JBuilder1.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 个开发工具中唯一完全使用
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
使用了专署的格式，因此其程序项目在进入了Repository 之后也发生过整个Repository 毁损
的情形，因此当时Visualage For Java 在易用性方面的分数是比不上其他竞争对手的。
对于Borland 的Open JBuilder1.0 来说，这个最晚进入竞争市场的工具在第一次的集体
评比中最后的结果不如人意。原本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 第一次公布HotSpot 的推出时程之后，果然让所有Java 的使用者都引颈期盼，
恨不得SUN 立刻推出这个技术，解除大众执行Java 的痛苦。不过随着时间的不断的接近，
SUN 在最后关头又宣布因为研发不及因此要延迟HotSpot 推出的时程。软件研发的工作延
后在软件界见怪不怪，当时也没有引起太多的争议，不但让SUN 争取到了更多的时间，也
顺利的延后了推出的时程。
不过当SUN 宣布的第二次推出时程到期时，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++语言的市场，并没有转换到Java 市场。这也是为什么后来C/C++市场虽然受
到了Java 的影响，但是仍然有大量的使用者和市场，并没有像当时许多人预测的那样将会
有大量的C/C++程序员进入Java 市场，终究还是因为Java 无法完全取代C/C++语言来完成
一些工作。而SUN 呢？为了转移大家对于HotSpot 的失望，而开始把研发重点转到
Internet/Intranet，EJB 组件模型和Java Mobil 系统方面的研发。轰动一时的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 的工具是走回头路，
到时Open JBuilder 会拥有最后的胜利，现在只是一时的挫折，没有必要灰心。
对于Borland 来说，如何继续Open JBuilder 是一个困难的抉择，因为当时Borland 继续
收入的注入，而Open JBuilder 的研发费用惊人，光靠Delphi 力撑实在是很辛苦。不过如果
再回头使用Delphi 开发，那么可能又会失去未来的机会，这到底应该如何决定呢？
Java 天才的加入
这一切的答案在Open JBuilder 的新产品架构领导人Blake Stone 加入后才逐渐明朗。
Blake Stone 原本是DSW Systems Corporation 公司的技术主管，而DSW 公司一向和Borland
互动良好，许多DSW 公司的人都曾在Borland 的Corference（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
JBuilder1.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 语言的
可用性。
第二点是因为打造纯Java 开发工具可以让JBuilder 通过Java 跨平台的特性把JBuilder
推向其他所有支持Java 的平台，让Borland 能够穿透到以往无法进入的市场，这样可以让
JBuilder 的潜在市场和客户比竞争对手的更宽广，更多。
第三点因素则是Blake 希望通过这个行动让Borland 掌握Java 的核心技术，最好能够和
SUN 有更密切的互动，让Borland 能够在Java 领域取得相关的领导地位。因为在和以往
Microsoft 交手的过程中，Borland 深深了解到如果无法在一个技术领域取得第一或是第二的
地位，那么终将成为微不足道的角色，被市场淘汰出局。
Blake 在JBuilder 研发方向制定的策略事后都被证明是正确的。后来JBuilder 果然能够
支持Windows，Linux 和Solaris 平台，成为当时架构最大，最复杂的Java 应用程序。更重
要的是SUN 充分肯定了Borland 在Java 方面做越的技术，进而采用Borland 的Baja 技术制
定Java BEAn 规格并且邀请Borland 共同参与开发Java 的JDK。Blake 在JBuilder 早期设定
了成功的趋势，奠定了JBuilder 成功的基础。稍后JBuilder 新的产品经理Tony De La Lama
又成功的制定了JBuilder 的市场研发脚步和竞争策略，终于让JBuilder 在3.5 版本之后一飞
冲天，成为Java 开发工具的翘首。
在Blake 加入JBuilder 开发团队并且决定了JBuilder 走向之后，很快整个JBuilder 的开
发方向便朝着他决定的方向快速前进。Blake 也激活了JBuilder 庞大的纯Java 开发工具的计
划。1998 年JBuilder 研发小组在Blake 的带领之下很快的交出了第一章成绩单，那就是
JBuilder 2 的推出。
JBuilder 2 的战略目标并不是成为完全的纯Java 开发工具，而是为了快速跟上其他Java
开发工具的功能，并且提升Open JBuilder 1.0 为人诟病的缓慢执行速度以及问题多多的窗体
设计家。
无疑JBuilder 2.0 是非常成功的。我所谓的成功并不是指JBuilder 在销售上的成功，而
是指Blake 为JBuilder 2.0 设定的目标。因为JBuilder 2.0 推出之后很明显的比Open JBuilder
1.0 看起来成熟多了，而且在执行速度，包含的功能等方面都达到了合理的地步，也让JBuilder
正式进入Java 开发工具第一方阵的竞争群。在Blake 的努力下，JBuilder 2.0 的实现程序代
码已经进步到使用25%Delphi 程序代码和75%Java 程序代码，离纯Java 开发工具已经愈来
愈近了。Borland 也开始从JBuilder 2.0 的身上看到了未来的曙光。也是上天注定，这个时候
正是Delphi 逼近于全盛的时期，需要JBuilder 接棒才能够让Borland 持续的成长。
（本章未完，待续）
希望更多的网友加入到录入的行列中来
第八章请参见:
http://www.delphibbs.com/delphibbs/dispq.asp?lid=2135073
http://www.delphibbs.com/delphibbs/dispq.asp?lid=2149792
------------------
Borland 传奇
作者：李维
第五章：逆转的奇迹——Borland JBuilder 的战斗发
展史
录入：windknight
·Java 开发工具初期的争战
·Borland 的Java 艰辛奋斗
·第一阶段－－Java JIT 编译器的战争
·Microsoft VJ++的威胁
·IBM Visualage For Java 的推出
·Java 集成开发环境的战争
·Hotspot 编译技术是个笑话吗？
·Borland 的困境和选择
·Java 天才的加入
·
·
·
·
·
“没有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 并没
有那么顺利。1995 年，当Java 开始起飞时，Borland 并没有预料到Java 成长的速度会如此
之快。Borland 一开始只是把Java 当成C/C++的延伸，因此只在Borland C/C++ 5.0 中加入了
支持Java 的Plug-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 Cafe.
Symantec 几乎是第一个接入Java 开发工具的软件公司，又利用了Symantec C/C++的
基础，因此在1995 年，当Java 获得愈来愈多人主义之后，Symantec 也准备好了他的第一个
Java 开发工具－－Visual Cafe。1996 年10 月，Symantec 赶在JDK1.1 之前正式推出了Visual
Cafe。虽然当时与许多人批评Symantec 为什么不等到JDK1.1 之后再推出，以支持最新的
JDK 标准（因为当时的JDK1.0x 版本有许多的问题），不过这些批评并没有妨碍Visual Cafe
的成功。
由于当时许多软件人员急于投入Java 的学习行列，因此当Symantec 推出了Visual Cafe
之后，立刻在市场获得了极大的成功。特别是在Java 学习市场和教育市场，Visual Cafe 几
乎是一席卷市场的姿势迅速占据了Java 开发工具第一名的地位，成为炙手可热的产品，而
Symantec 公司也一扫在C/C++开发工具被挫败的怨气，再次成为开发工具市场的领导厂商。
由于当时Microsoft 对于Java 采取敌视的态度，因此几乎不可能推出Java 开发工具，而
Borland 也正陷于C/C++的苦战之中，尚未察觉到Java 的潜力。至于另外一个死对头Watecom
则已经被Sybase 并购，无法在开发工具市场再成气候。这对于Symantec 来说简直是天赐良
机，一个可以独打Java 开发工具市场的绝佳机会。剩下唯一的威胁是SUN 要推出的Java
开发工具。但是Symantec 已经抢得市场先机，而且已经成为领先者，只要好好的把握，就
能够以逸待劳和SUN 对战。在这个Java 开发工具萌芽的阶段，Symantec 似乎是占了绝对的
优势，不过很可惜的是接下来Symantec 也接连犯了几个错误，逐渐失去了取得的优势。
首先是当Visual Cafe 推出之后，Eugene Wang 便离开了Symantec 自己开公司做生意去
了。这对于Visual Cafe 有着相当大的影响，因为Symantec 靠着Eugene Wang 的技术能力和
眼光，才能够和Microsoft，Borland 和Watcom 在C/C++开发工具市场对抗：Eugene Wang
又独具慧眼打造了第一个Java 开发工具Visual Cafe。Symantec 应该在Visual Cafe 获得初期
的胜利之后再次借重Eugene Wang 的功力继续攻城掠地，但是Symantec 居然让Eugene Wang
离开，立刻少了开发工具掌舵的大将。
第二个错误是Symantec 当初为了尽快推出Visual Cafe 以抢占市场先机，因此集成开发
环境是使用C/C++语言撰写的。这造成了数项缺点，其一是由于使用了C/C++来撰写可视化
窗体设计家（Visual Form Designer），因此程序员在设计时看到的可视化效果和真正Java 程
序执行时的效果是有一些差异的；其二是为了维护Java 的控制组件程序代码和以C/C++撰
写的可视化窗体设计家保持同步的状态，在可视化状体设计家产生的原始程序代码中内嵌了
一些Visual Cafe 控制卷标（Control Tag）。这些控制卷标并不是Java 的程序代码，只是为了
可视化窗体设计家使用。如果程序员不小心修改或时删除了这些控制卷标，就会造成Visual
Cafe 的可视化窗体设计家的失效。这是非常严重的缺点，Symantec 应该在Visual Cafe1。0
之后立刻改善这些问题，然而Symantec 似乎一直无法有效地加以改善。当然，问题的根源
在于Visual Cafe 的集成开发环境是使用C/C++语言撰写的，要完全改善这个问题，Symantec
必须使用Java 语言重新改写集成开发环境，这正是Borland 后来采取的策略。不过使用Java
撰写集成开发环境也是非常冒险的行动，Borland 后来因此付出了沉重的代价。Symantec 之
所以没有如此做，大概也是因为当时的Java 并没有成熟到可以如此做的地步。不过SUN 显
然不这么认为，其对Java 信心百倍，不久就推出了SUN 的Java 开发工具，Java Workshop。
当Java 成功的掳获了开发者得心之后，对于Java 开发工具的要求便于日俱增。虽然
Symantec 已经推出了Visual Cafe，但是许多人仍然希望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
之后，才发现它不但执行缓慢的像乌龟一样，而且问题多多，和一般的PC 开发工具水准比
起来简直是差了十万八千里。看来Java Workshop 只是和使用在昂贵的SUN 工作站计算机
上，而在当时大多数人使用的PC 上则根本跑不动，除非使用有异于常人的耐性。
Java Workshop 雷声大雨点小，不久之后就人气溃散了。许多原来对Java 有信心的人在
用了Java Workshop 之后，也开始质疑Java 是否适合是用来开发复杂的应用程序？是不是只
适合用来专习Applet？是不是只适合使用在SUN 的工作站和计算机之上？虽然之后SUN 仍
然很努力的推出了Java Workshop2.X 的版本，希望一洗Java Workshop 1.X 的恶名，但是仍
然无法挽回Java 开发人员的信心。至于其他仍然对Java 有兴趣的人则转而使用Symantec
的Visual Cafe，让Visual Cafe 进一步的扩大了市场占有率，也让Symantec 吃了一颗定心丸。
当然也有许多Borland 的支持者开始强烈的期望和要求Borland 能够推出最好的Java 开发工
具。
SUN 在Java 开发工具市场大溃败之后，才了解到PC 开发工具市场和Solaris 开发工具
市场不一样。在Solaris 上SUN 是一家独大，但是在PC 市场尚可是百家争鸣，竞争对手一
个比一个强悍。SUN 不了解PC 开发工具市场的特性，一味靠着Java 正宗的招牌就可以通
行无阻却是大错特错，并且在当时被Micorsoft 讥笑不懂得开发软件，这也是因为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 Cafe 早已成功的上市，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 开发工具的内部研发名称便是Latte。一开始Latte 小组的研
发资源并不够多，因为当时的Borland 是在风雨飘摇之中，无法注入足够的资源到Latte 小
组。因此在Latte 开始开发的初期进展得并不顺利，进度很缓慢。一直到了Borland 靠Delphi
浴火重生之后，Latte 小组才有了足够资源，研发的进度才开始加速。不过与竞争对手们比
起来，Borland 在Java 方面的确是相当落后的，几乎是跑在最后的参赛者。不过幸运的是Java
开发工具之战似乎是一场漫长的马拉松比赛，除了一开始的表现之外，更重要的是比谁能构
成的比较久。事实上看Borland 如何在Java 竞赛场上反败为胜，一一打败强者，进而成为
Java 开发工具王者的过程是相当精彩的，而JBuilder 小组使用的竞争策略更值得我们玩味和
学习。
依我个人眼光来看，在Borland 开发Java 开发工具的过程中经历了数个不同的阶段，每
一个阶段都有着非常激烈的竞争，有着成功者和失败者。只是有的失败者仍然坚持竞争下去，
有的却随风消散。JBuilder 最终能够成为王者，除了是因为愈挫愈勇，Borland 并没有退出
Java 市场之外，还在于Borland 在开发JBuilder 3 是下了一个关键性的决定，以及在JBuilder
3 之后每一个版本都有明确的目标，终于在JBulider 4之后慢慢成为市场第一的领导者。当
然这长达数年的征战过程是非常艰辛的，不过这段历程正是整个Java 开发工具逐鹿中原的
写照史
第一阶段－－Java JIT 编译器的战争
Borland 也许不是最晚开始研发Java 技术的厂商，但是明显是落后于其他竞争对手则是
不正的事实。Borland 在Latte 万事尚未具备的情形下，展开Java 竞赛的第一步便是从Borland
传统的拿手绝活开始，那就是从Java JIT 编译器开始出发。不过由于Borland 当时对于Java
技术尚未拥有良好的掌握，因此一开始是和Pascal 的祖师爷Dr.Niklaus Worth 合作，有
Dr.Niklaus Worth 以及他的学生们为Borland 研发Java JIT 编译器，而Borland 本身的Latte
小组则平行的开发Latte 其他的功能。由于当时Java 已经逐渐在校园流行，而且吸引了许多
学术研究的兴趣，Dr.Niklaus Worth 以及他的学生们很早便开始投入Java 相关的研究。因此
当Borland 找上门之后，自然便一拍即合。Borland 缩短了开发时程，而Dr.Niklaus Worth 研
究小组则乐得有人赞助研发费用。
Dr.Niklaus Worth 研究小组的第一个作品就是在1997 年初左右推出的Java JIT 编译器，
这个由Dr.Niklaus Worth 研究小组研发的JIT 编译器可以让编译后的Java Btyecode 执行速度
比当时的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 的处女作JavaJIT 编译器一炮而红，立刻吸引了当时浏览器霸主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 在全世界将立刻拥
有数百万的Latte 潜在使用者，对于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 编译器的竞赛，以求全速催生Latte。
当然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 Cafe 中，成为一项吸引人的功能。不过很快这个功能却引起了许多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 Cafe 在JBuilder，Visual Age For Java 陆续推出之后市场占
有率已经慢慢的被瓜分，现在有得再次面对Microsoft 的竞争，昔日Symantec C/C++失败的
阴影又缠上了心头。而Microsoft 的死对头IBM 更是在Visualage For C/C++，Visualage For
BASIC 连番失败之后，好不容易推出了Visualage For Java，准备在Java 开发工具市场打一
场好球赛，没有想到现在Micorsoft 又来搅局。
对于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 开发工具都有可能造成威胁，那么VB 将会使受到影响最大的开发工具。但
Borland 仍然感到忧心，因为VJ++仍然可能对于Delphi 和C++Builder 产生一定的影响，这
是Borland 不乐意看到的。当然这也加速了Borland 研发Latte 的决心，因为已经不能再拖了。
记得我当时还和Borland 在亚洲新加坡R&D总部的Mr.Inn Nam Yong 谈过VJ++的表现
以及对于VJ++可能产生影响的忧虑。Mr.Young 也说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 开
发工具的威胁也很快的接触了。V++对于Microsoft 来说很可能是自DOS 版的Microsoft
Pascal 之后的地而此在开发工具的大失败。不过依我的观点来看，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#编译
器的最佳化结果也在一些方面胜过了现在许多原生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 Cafe 以及JBuilder 锁定的客户群不同，因此在Java 开发工具竞争初期并没有发生严
重的竞争冲突。但是随着Visual Cafe和JBuilder 逐渐往上仰攻企业市场，而Visualage For Java
为了扩大市场而开始降价进入一般Java 大众市场之后，稍后的Java 开发工具恶战也不可避
免了。
第二阶段――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 等。当
时的Latte 小组有许多成员是从以前的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 逐渐势力于桌上型数据库战场之后，便转到Latte 小组专门负责设计Latte 的组建
架构。
而JBCL 的主要实现工程师则是当初设计和实现Borland C/C++ Framework－OWL 的总
工程师Carl Quinn。Carl Quinn 在组件设计和Framework 方面都有丰富的经验，OWL 就技
术而言也算是精品。因此在Borland C/C++产品线停止以后，Carl Quinn 由C/C++转换到Java
跑道是很自然的事情，毕竟C/C++和Java 是很类似的。Carl 拥有丰富的经验，由他来带领
开发Latte 的组件Framework 是再合适不过了。
由于Carl 在JBCL 的努力和成果，稍后又负责了Borland 的Java 组件模型Baja 的开发。
之后Carl 凭借这对于JBCL 和设计Baja 的经验，在SUN 采用Baja 作为JavaBEAn 的核心基
础技术之后便自然的受邀于JavaBEAn 的开发小组。由于Borland 在Java 组件方面卓越的表
现，因此也开启了SUN 和Borland 逐渐密切的合作。Borland 虽然在Java 方面投入的时程稍
晚，但是却凭借着扎实的技术而慢慢迎头赶上。
Latte 的Framework 开发在Joe Nunoll 和Carl Quinn 的带领之下有了稳定的发展。事实
上JBCL 的表现一直是非常优秀的。当Latte 随后正式推出时，JBCL 也是让Latte 得以脱颖
而出的重要功能之一。Joe Nunoll 和Carl Quinn 的功劳可谓不小，而我钦佩的Carl Quinn 又
再次在Java 方面证明了他坚实的技术和在Framework 方面丰富的设计和实现经验。
Java Framework 虽然重要，但也只是整个完整开发工具的支柱之一。Latte 要推出仍然
需要编译器和集成开发环境的功能。在Java 编译器方面，Borland 和结束委托Dr.Niklaus
Worth 研究小组开发Java JIT 编译器之后，Latte 开发小组便开始展开研究的工作。当时JIT
编译器已经全面开战，而Borland 在Latte 尚未推出，还没有足够资源的情形下如果再介入
JIT 的战争，那么不但胜算不大，而且可能会严重影响Latte 的推出时程。因此Latte 小组决
定先转行开发一个编译品质良好，而且能够和Latte 完美搭配的Java 编译器，而不再强求效
率之上。
从现在的观点来看，当时Latte 小组的决定是非常正确的。因为：第一.当时Borland 的
确没有太多的子弹；第二，Latte 的时程再也不能拖延；第三，也是最重要的是稍后SUN 宣
布了开发Hotspot 编译器技术的计划，顿时所有Java JIT 编译器的风头都被SUN 抢走了。特
贝是在稍后SUN 决定将Hotspot 内建在JDK 中之后，争夺Java JIT 编译器不但变得没有意
义，而且对于Java 开发工具而言也没有什么附加价值了。因此在SUN 的Hotspot 编译技术
揭露之后，Symantec 很快就在Java JIT 编译器市场上销声匿迹了。
Latte 小组确定了Java 编译器的策略之后，立刻便接手Dr.Niklaus Worth 研究小组的后
续开发工作，同时开发Latte 的编译器，Latte 的Plug-in 以整合Java 编译器到Latte 的集成
开发环境中，并且也进行Java 编译器最优化的研究工作。当时按各Java 编译器开发小组由
Carl Fravel 等仍带领，同时也包括了Borland 的编译器小组。Carl Fravel 主要负责Latte 的编
译器以及编译器的Plug-in 软件软件，此外他也参于了Latte 数据库方面的开发。当时Java
数据库存取方面仍然相当弱势，Borland 为了加强Latte 这方面的功能，决定先借重Delphi
在数据库方面的成绩，即通过JDBC 标准接口粉状Delphi 已经有的各种数据库驱动程序，
让Latte 能够立刻联接到最多的数据库，这就是后来JBuilder 的DataGateway。
除了Carl 之外（嗯，Latte 开发小组里有两个Carl），Sergio Cardoso 也是Latte 编译器最
佳化的成员。Sergio 原本是Borland C/C++的开发者之一，专门研究C/C++最佳化的技术，
他和Carl Quinn 等人一样转移到Java 的产品线。Sergio 和Carl Fravel 合作，负责打造Latte
的核心引擎。在Latte 上市之后，事实上每一版的JBuilder 的编译器都有进步。就现在来说，
在JBuilder 7／8 中编译Java 应用程序相当的快速。这说明JBuilder 和当初Borland C/C++一
样，都是在初期版本快速的强化引擎，不断的提升速度。
当时的Latte 并没有一个真正的总Architect，只有不同技术领域的Architect，例如Joe
Nunoll。因此Latte 当时主要的舵手应该是产品经理以及Borland 的Java 资深研究员了。而
产品经理以及Java 资深研究员再和所有的各领域Architect 讨论Latte 的开发方向。因此在
Latte 的初期开发阶段，其模式就象罗马时期的和一致。
当时的Latte 产品经理是Klaus Krull（K.K.）。这位仁兄长的又高又大，也是一位相当热
心的人。K.K.原本是Paradox 和dBase 小组的成员，负责Paradox/dBase 的产品线。在Latte
小组成立之后K.K.立刻跳槽到Java 产品线来。事实上许多Paradox/dBase 的工程师也都希望
转换到Java 产品来，因此当时在Borland 内部掀起了很大的风浪，也造成了许多人离职。这
段故事在稍后的dBase 相关章节中将详细说明。
K.K.加入了Latte 小组之后，便积极的带领Latte 小组往前冲。或许是因为K.K.在Paradox
和dBase 时表现得并不好，因此想借着Latte 证明自己的实力。不过K.K.人也许很好，可是
管理方面似乎仍然不甚灵光，Latte 初期的进度仍然稍嫌缓慢。在IBM Visualage For Java 于
1997 年推出之后，Borland 高层下令K.K.绝对不可以再度延迟进度，一定也要在1997 年推
出第一个Latte 版本。好在当时Delphi3 大获全胜，而K.K.又是当时Delphi产品经理Ben Riga
的好哥们，因此由Delphi 转入Latte 的资源也就源源不绝，让Latte 的进度慢慢的赶上了。
至于当时Latte 架构的主要任务并不是稍后众人皆知的Blake Stone，因为Blake Stone
是在Latte 推出之后才加入Borland 的。Latte 初期的架构负责人是Steve Shaughnessy。
Steve 是Borland 的自身研究人员，也是当初Borland 最早投入Java 技术研究领域的人
物之一。不过自身研究人员的缺点之一是喜欢不断的想象以及研究软件技术，但是对于产品
进度的掌握却不是他们的专长，也不是他们关心的事情。这就是为什么Latte 一开始的开发
进度非常缓慢的原因。直到最后K.K.加入并且面临了Borland 高层和市场巨大的压力之后才
匆匆的集中所有的资源和时间想要追上进度。
当Latte 小组开发JBuilder 的第一个版本时，就象学习使用Delphi成功的Open Tools API
特性，为JBuilder 定义完整而且极其弹性的开放式集成开发环境。不过由于当时Delphi 的
Open Tools API 仍然没有大量的采用接口程序设计的架构，考虑到Java 拥有定义良好的接口
机制，无法完全采用Delphi 的Open Tools API 的设计，所以一开始JBuilder 集成开发环境的
Add-ins 功能开发环境中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 月，Latte 终于完成并且推出市场。正式的产品名称被定义为Open JBuilder，
这是为了强调Borland 的Java 开发工具就像Java 本身一样是使用开放的架构。
在Open JBuilder 1.0 推出之后，Java 开发工具市场总算是竞争者齐聚一堂了，每一家厂
商终于一一的使出了真本领来竞逐Java 开发工具的市场龙头。Open JBuilder1.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 个开发工具中唯一完全使用
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
使用了专署的格式，因此其程序项目在进入了Repository 之后也发生过整个Repository 毁损
的情形，因此当时Visualage For Java 在易用性方面的分数是比不上其他竞争对手的。
对于Borland 的Open JBuilder1.0 来说，这个最晚进入竞争市场的工具在第一次的集体
评比中最后的结果不如人意。原本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 第一次公布HotSpot 的推出时程之后，果然让所有Java 的使用者都引颈期盼，
恨不得SUN 立刻推出这个技术，解除大众执行Java 的痛苦。不过随着时间的不断的接近，
SUN 在最后关头又宣布因为研发不及因此要延迟HotSpot 推出的时程。软件研发的工作延
后在软件界见怪不怪，当时也没有引起太多的争议，不但让SUN 争取到了更多的时间，也
顺利的延后了推出的时程。
不过当SUN 宣布的第二次推出时程到期时，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++语言的市场，并没有转换到Java 市场。这也是为什么后来C/C++市场虽然受
到了Java 的影响，但是仍然有大量的使用者和市场，并没有像当时许多人预测的那样将会
有大量的C/C++程序员进入Java 市场，终究还是因为Java 无法完全取代C/C++语言来完成
一些工作。而SUN 呢？为了转移大家对于HotSpot 的失望，而开始把研发重点转到
Internet/Intranet，EJB 组件模型和Java Mobil 系统方面的研发。轰动一时的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 的工具是走回头路，
到时Open JBuilder 会拥有最后的胜利，现在只是一时的挫折，没有必要灰心。
对于Borland 来说，如何继续Open JBuilder 是一个困难的抉择，因为当时Borland 继续
收入的注入，而Open JBuilder 的研发费用惊人，光靠Delphi 力撑实在是很辛苦。不过如果
再回头使用Delphi 开发，那么可能又会失去未来的机会，这到底应该如何决定呢？
Java 天才的加入
这一切的答案在Open JBuilder 的新产品架构领导人Blake Stone 加入后才逐渐明朗。
Blake Stone 原本是DSW Systems Corporation 公司的技术主管，而DSW 公司一向和Borland
互动良好，许多DSW 公司的人都曾在Borland 的Corference（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
JBuilder1.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 语言的
可用性。
第二点是因为打造纯Java 开发工具可以让JBuilder 通过Java 跨平台的特性把JBuilder
推向其他所有支持Java 的平台，让Borland 能够穿透到以往无法进入的市场，这样可以让
JBuilder 的潜在市场和客户比竞争对手的更宽广，更多。
第三点因素则是Blake 希望通过这个行动让Borland 掌握Java 的核心技术，最好能够和
SUN 有更密切的互动，让Borland 能够在Java 领域取得相关的领导地位。因为在和以往
Microsoft 交手的过程中，Borland 深深了解到如果无法在一个技术领域取得第一或是第二的
地位，那么终将成为微不足道的角色，被市场淘汰出局。
Blake 在JBuilder 研发方向制定的策略事后都被证明是正确的。后来JBuilder 果然能够
支持Windows，Linux 和Solaris 平台，成为当时架构最大，最复杂的Java 应用程序。更重
要的是SUN 充分肯定了Borland 在Java 方面做越的技术，进而采用Borland 的Baja 技术制
定Java BEAn 规格并且邀请Borland 共同参与开发Java 的JDK。Blake 在JBuilder 早期设定
了成功的趋势，奠定了JBuilder 成功的基础。稍后JBuilder 新的产品经理Tony De La Lama
又成功的制定了JBuilder 的市场研发脚步和竞争策略，终于让JBuilder 在3.5 版本之后一飞
冲天，成为Java 开发工具的翘首。
在Blake 加入JBuilder 开发团队并且决定了JBuilder 走向之后，很快整个JBuilder 的开
发方向便朝着他决定的方向快速前进。Blake 也激活了JBuilder 庞大的纯Java 开发工具的计
划。1998 年JBuilder 研发小组在Blake 的带领之下很快的交出了第一章成绩单，那就是
JBuilder 2 的推出。
JBuilder 2 的战略目标并不是成为完全的纯Java 开发工具，而是为了快速跟上其他Java
开发工具的功能，并且提升Open JBuilder 1.0 为人诟病的缓慢执行速度以及问题多多的窗体
设计家。
无疑JBuilder 2.0 是非常成功的。我所谓的成功并不是指JBuilder 在销售上的成功，而
是指Blake 为JBuilder 2.0 设定的目标。因为JBuilder 2.0 推出之后很明显的比Open JBuilder
1.0 看起来成熟多了，而且在执行速度，包含的功能等方面都达到了合理的地步，也让JBuilder
正式进入Java 开发工具第一方阵的竞争群。在Blake 的努力下，JBuilder 2.0 的实现程序代
码已经进步到使用25%Delphi 程序代码和75%Java 程序代码，离纯Java 开发工具已经愈来
愈近了。Borland 也开始从JBuilder 2.0 的身上看到了未来的曙光。也是上天注定，这个时候
正是Delphi 逼近于全盛的时期，需要JBuilder 接棒才能够让Borland 持续的成长。
（本章未完，待续）
][^]