按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
他们害怕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 计划的基础核心技术之中。例如C#的语言和Java很相像，
C#的编译器技术想必也借重了许多当初VJ＋＋优秀编译器的技术，因此C#编译器的最佳
化结果也在一些方面胜过了现在许多原生Windows开发工具的编译器水准。Anders
Hejlsberg的努力正激活了Java和的正面决战。
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 ponent 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开发工具大会�