究员了。而产品经理以及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 piling〃技术来加快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 piling〃非常的有创意，但是要和已经存在数年的C＋＋最佳化编译
器比起来，Java的ByteCode是不可能超越C＋＋的。但是从SUN在其时公布的一些HotSpot
编译数字来看，〃Adaptive piling〃是非常有希望的，因为它改善的幅度实在是很
大。因此全球相关的人员都在屏息以待，准备看看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的编译品质在伺服端的效率有着显著�