按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
负责Delphi的开发工作后不久，就把Delphi Architect以及重要的工作交由Danny来
负责，因为Danny早已显示了大将之风，成为Chuck最为信任的软件专家。而Chuck呢？
虽然他仍然负责Delphi中许多重要的工作，但是后来大部分的时间是花在新技术和新
产品的秘密研究之中。对于一些Delphi例行性的工作，Chuck并不会花费太多时间。
在Delphi 3的研发阶段，Chuck的主要精力并不是在Delphi 3上，因为Danny和Zack负
责得很好。Chuck当时主要是进行两件重要的研发工作，即Delphi的Java编译器以及
Apollo计划。
原来，在开发Delphi 3时，Anders和Chuck都已经预知了Java将来必会成功，成为重
要的语言和软件技术。因此Anders和Chuck都知道必须在Java方面进行一些因应之道，
以未雨绸缪保持Delphi的竞争力。后来Anders离开了Borland，而Chuck则选择了投入
资源研究Delphi和Java的整合技术。当时Chuck的想法是为什么不能够开发一个类似
Java的JVM，直接把Delphi的程序代码转换为Java的ByteCode，让Delphi的应用程序
直接在JVM中执行呢？甚至，当时Chuck还想，为什么Borland自己不开发一个Delphi
JVM，让Delphi也可以执行在Windows、Linux、Solaris和Mac OS之中呢？
有了这个疯狂的想法之后，Chuck立刻要求Borland的高层批准这个研究计划，让他能
够有资源进行研究工作。由于当时正值Anders因为不满在Borland没有足够的研究资
源而离开了Borland，进入Microsoft一展心中的鸿图。因此，Borland高层当然不愿
得罪Chuck，以免他也离开Borland。由于当时Delphi 3的进度在掌握之中，而且
Delphi为Borland带来了大量的资源，因此Borland高层批准了Chuck的这个不可思议
的计划，让Chuck开始了研究之路。
Chuck有了资源之后，就立刻投入研究的领域，在Delphi 3的开发末期也没有花太多
的时间在Delphi上，反而加速地和Borland的编译器小组为Delphi For Java编译器进
行研发工作。在1997年中左右，Chuck有了初步的成果，已经能够把一些简单的
Object Pascal程序直接编译成Java的ByteCode、并且执行在JVM之中。这实在是一个
不小的突破，因此在当年的BorCon 1997中，Borland和Chuck正式对外公开了这个技
术，立刻引起了Delphi使用者强烈的兴趣，因为这代表一旦这个编译器研发出来，
那么Object Pascal便立刻成为一个像Java一样的跨平台程序语言，而且，如果
Borland能够继续把VCL和RTL移植进来，那么，Windows平台的Delphi程序员可以通
过这个技术同时开发多个平台的应用程序，这实在是太美妙了。
当BorCon公开了这个技术之后，Borland立刻面临了愈来愈多的Delphi使用者的询问
以及要求Borland尽早推出这个技术的压力。当然，Chuck以及Delphi研发小组也非常
兴奋，因为这代表Delphi又将有新的市场以及新的成长动力，所以Chuck立刻要求
Borland投入更多的资源，以加速研究这个Delphi For Java编译器以及相关的研究工
作。
不过，此时却发生了两件事情，最终让Chuck放弃了继续开发Delphi For Java编译器
的意图。首先，Chuck和Borland的编译器开发小组发现JVM似乎和Java语言系结得太
紧密，以致JVM的许多伪指令都和Java语言的架构系结在一起，无法轻易地由其他语
言来提供类似Java语言的架构，除非修改这些语言架构来仿真Java语言的架构。这个
原因造成了当Chuck想把Object Pascal一些复杂的数据类型和语言架构编译成Java
ByteCode时发生了极大的困难。
第二个决定性的原因是，由于当时JBuilder已经表现得愈来愈好，Borland希望投入
更多的资源到JBuilder小组，而且不希望有其他的产品或是技术影响JBuilder的成长，
因此，Borland高层对于Delphi For Java编译技术的开发也没有很大的兴趣，再也
没有批准更多的资源给Chuck。最后，Chuck的这个Delphi For Java编译计划便宣告
终结了。这实在是件可惜的事情，不过，当时Chuck研究的东西并没有白费，因为现
在Delphi小组也根据当时Chuck研究的成果来开发上的编译器，希望通过以前投
入的资源和经验来开发更好的Delphi For 编译器。
另外一个Chuck在Delphi 3开发阶段秘密进行的研究计划则更为重要了。当时我更期
望这个技术能够出现在市场之上，不过可惜的是，最后也由于Borland高层要求Chuck
投入Kylix的研发工作而一直拖延到今日都还在软件实验室中，这就是属于Data
ponent技术的Apollo计划。
Apollo项目的缘由要从Delphi 2开始说起。在Delphi 2开发时，Anders一直想在Delphi
中建立一个Garbage Collection的功能，而Chuck则希望继续扩充VCL的功能为VCL加
入Data ponent的能力。由于VCL使用的组件架构在连接数据时是使用数据感知组
件（Data Aware）技术，但是许多真正使用面向对象技术的程序员反而对使用数据感知
组件相当地反感，而且在大型面向对象项目中，数据感知组件也被证明是不适当的。
因此Chuck为了赋予VCL开发大型面向对象项目的能力，决定加入Data ponent技术
。
所谓Data ponent技术，是指VCL架构可以代表实际世界中的domain对象，这些
domain对象可通过VCL的技术直接储存在数据库之中，或是从数据库中取出，类似EJB
中的OR Mapping（Object…Relational Mapping）技术。如此一来，Delphi的程序员可
以在Delphi中直接使用VCL组件来代表如员工和公司等实例（instance），而且可以随
时把员工和公司实例储存到数据库中，再从数据库中取出员工和公司成为对象，而不
需要使用数据存取对象直接处理数据库中的数据。Chuck早在五六年前就想在Delphi
中实现目前Bold等公司提供的Object Instance技术。
没有想到，就在Chuck进行Apollo项目到了一半的时候，由于当时Borland的CEO Dale
Fuller先生看好Linux的发展，因此下令所有Delphi小组的成员都必须投入到Linux
开发工具的研发工作，全力为Kylix催生，于是连Chuck也被要求先暂缓所有的研究计
划，投入Kylix的开发工作。其实，当时我就非常反对像Chuck这样的顶尖人才进入
Kylix小组撰写程序代码，因为这实在是非常浪费的事情。Chuck应该进行更为重要的
研究计划，而不是只开发一般的工具而已。但是，当时Borland高层认为Linux将可带
领Borland一飞冲天，因此仍然坚持所有的人力都必须投入。不过，市场就是变化得
这么快，在Chuck和Danny都投入到Kylix的开发之后，虽然Delphi小组几乎以创记录
的时程在1年半左右就在一个新的平台开发了一个新的产品线，但是在Kylix推出之
后，Linux平台的疯狂热潮却开始快速消退。所有投入Linux的厂商再也无法仅以沾
上Linux的名称就可以让股票日创新高，市场终究是要回到基本点，只有真正获利的
公司才能够在市场成为赢家。
在Chuck被Kylix开发工作延误了近2年的时间后，Apollo再也不像当初那么吸引人了，
因为市场已经出现了类似的科技，例如EJB的OR Mapping技术和Bold等公司的产品。
如果Borland当初能够让Chuck全力发展Apollo计划、并且在其他公司之前推出Apollo
的成果，那么Delphi将可以在OR Mapping方面占有领导的地位，Borland研究的OR
Mapping技术说不定还可以被SUN授权使用，就像Oracle花了大钱从WebGain购买类似
的技术一样。Anders和Chuck这两位拥有一流技术和眼光的技术人物，或多或少地被
许多平凡的管理人物糟蹋了好几次。
Chuck本身是一位非常和蔼可亲的人物，我曾经多次和Chuck交谈，每次谈话时Chuck
总是笑嘻嘻的，似乎没有事情可以让他感到忧虑。如果不知道Chuck的人和Chuck交谈，
那么可能没有人会相信，这位看起来像是好好先生的人在软件方面有这么惊人的成
就和高深的造诣，而Chuck一头接近红色的头发也让我第一次见到他时被吓了一跳。
当Chuck和Danny被征召开发Kylix时，�