【導(dǎo)讀】"沒有JBuilder，Borland就不可能擁有今日的榮景！意外，但是成功者一定是果斷而且行動迅速的。當(dāng)SUN察覺到Java的光明未來之后，便立刻開始大力推銷Java。SUN的總裁McNealy先生數(shù)年來苦于沒有直接和Microsoft. 串行動都被證明是正確而成功的。這些行動包括和各種廠商合作；與Addison-Wesley. 關(guān)的文章、專欄等；快速培養(yǎng)Java使用者的基礎(chǔ)，吸引大眾對于Java的興趣。更重要的是McNealy立刻果斷地投入大量的研發(fā)資源，不斷地改善Java，史上最大規(guī)模對抗Microsoft的爭霸戰(zhàn)，也改變了許多軟件開發(fā)的習(xí)慣和方向。過的大規(guī)模集團軍混戰(zhàn)。對于Borland來說，事情并沒有那么順利。1995年，當(dāng)Java開始起飛時，Borland并沒。有預(yù)料到Java成長的速度會如此之快。因此只在BorlandC/C++中加入了支持Java的P1ug-In。在Java開發(fā)工具找到了新舞臺，而且發(fā)展得相當(dāng)快速。Borland如何才能在下一場最重要的開發(fā)工具大戰(zhàn)中進行。由于當(dāng)時許多軟件人員急于投入Java的學(xué)習(xí)行列，因此當(dāng)Symantec推出了VisualCafé剩下唯一的威脅是SUN. 境也是非常冒險的行動，Borland后來因此付出了沉重的代價。

　　

【正文】 執(zhí)行效率緩慢 的主要原因當(dāng)然是 Java 編譯器以及 JVM 的品質(zhì)不夠精良了。 為了急于讓信息界接受 Java成為標(biāo)準(zhǔn)， SUN 必須想辦法克服這個問題。雖然克服 Java 執(zhí)行緩慢的現(xiàn)象是當(dāng)時幾乎所有支持 Java軟件廠商都想解決的事情，但 Java的正宗廠 商 SUN 是責(zé)無旁貸的。也是因為 Java 執(zhí)行效率的緩慢，當(dāng)時也興起了許多小的軟件廠 商開發(fā)各種技術(shù)和編譯器來改善或是解決 Java 的這個致命缺點。很快 SUN找到了一家 小軟件公司，這家公司以開發(fā)出 Adaptive Compiling技術(shù)來加快 JVM執(zhí)行效率、以 及使用類似的技術(shù)來 改善 Java 編譯器的品質(zhì)而聞名。 SUN 在了解到這些杰出的技術(shù)之 后便立刻決定購買這家公司，并且根據(jù)他們的技術(shù)來實現(xiàn) SUN 的下一代 Java編譯器以 及 JVM，這就是稍后 SUN HotSpot 技術(shù)的由來。 SUN 投入新的 Java編譯技術(shù)之后不久，就有了初步的結(jié)果。根據(jù)這個新的技術(shù)編譯出 來的 Java ByteCode 以及新的 JVM 的執(zhí)行效率果然比以前進步了許多。這讓 SUN更有信 心，便立刻向世界公告了這個新的技術(shù)，并且命名為 HotSpot。 SUN宣稱最后推出的 Java 編譯器和 JVM 將提供類似 C++的執(zhí)行效率 。 在 SUN 公布了 HotSpot 技術(shù)之后，立刻引起了全世界 Java 使用者的狂熱。人們認(rèn)為一旦 SUN 推出這個技術(shù)， Java將可望克服最后一個缺點，從而一統(tǒng)天下。與此同時，這也 引起了信息業(yè)界非常大的討論和爭議。特別是 C/C++社群的人認(rèn)為這根本是不可能的， 雖然 Adaptive Compiling非常的有創(chuàng)意，但是要和已經(jīng)存在數(shù)年的 C++最佳化編譯 器比起來， Java 的 ByteCode是不可能超越 C++的。但是從 SUN在其時公布的一些 HotSpot 編譯數(shù)字來看， Adaptive Compiling是非常有希望的，因為它改善的幅度實在是很 大。因此全球相關(guān)的人員都在屏息以待，準(zhǔn)備看看 SUN 最后的成果。 在 SUN 第 1 次公布 HotSpot 的推出時程之后，果然讓所有 Java的使用者都引頸期盼，恨 不得 SUN 立刻推出這個技術(shù)，解除大眾執(zhí)行 Java的痛苦。不過隨著時間不斷的接近， SUN 在最后關(guān)頭又宣布因為研發(fā)不及因此要延遲 HotSpot推出的時程。軟件研發(fā)的工作 延后在軟件界見怪不怪，當(dāng)時也沒有引起太多的爭議，不但讓 SUN爭取到了更多的時 間，也順利地延后了推出的時程。 不過在 SUN 宣布的第 2 次推出時程 到期時， SUN 仍然無法推出 HotSpot技術(shù)。很快的 SUN 不得不再次宣告要延后 HotSpot的時程。就在這樣 SUN 不斷跳票的戲碼重復(fù)上演的情形 下，終于開始有人笑稱 HotSpot根本是一個騙局， SUN 根本無法推出接近 C++執(zhí)行效率 的 Java 編譯技術(shù)。 到了 1999 年左右， SUN 自知再也無法推拖 HotSpot 推出的時程了。因此在當(dāng)年 8月，當(dāng) 時 HotSpot研發(fā)小組的領(lǐng)導(dǎo)人 (一位博士，但是我已經(jīng)忘記了他的名字 )在 BorCon上進 行 Keynote Speech，正式向參加 BorCon 的人介紹 HotSpot技術(shù)并且在現(xiàn)場展示了 HotSpot 的研發(fā)成果。雖然一切看起來都很棒，但是當(dāng)現(xiàn)場的聽眾直接詢問到底 HotSpot技術(shù) 是否能夠超越 C++的執(zhí)行效率時，這位博士卻沒有正面回答，只解釋說在一些應(yīng)用中 HotSpot的確可以提供超越 C++的執(zhí)行效率。我聽了之后心中大概就已經(jīng)知道 HotSpot 最終的結(jié)果了。 果然在 HotSpot 被迫推出市場之后，大家很快地了解到 HotSpot和 C++的執(zhí)行效率相比 終究是還有一段距離，根本無法超越 C++的表現(xiàn)。這造成了當(dāng)初一些熱切期待的 C/C++ 程序員回到 C/C++語言的市 場，并沒有轉(zhuǎn)換到 Java 市場。這也是為什么后來 C/C++市 場雖然受到了 Java 的影響，但是仍然有大量的使用者和市場，并沒有像當(dāng)時許多人預(yù) 測的那樣將會有大量的 C/C++程序員進入 Java市場，終究還是因為 Java 無法完全取代 C/C++語言來完成一些工作。而 SUN呢？為了轉(zhuǎn)移大家對于 HotSpot的失望而開始把研 發(fā)重點轉(zhuǎn)到 Inter/Intra、 EJB 組件模型和 Java Mobile系統(tǒng)方面的研發(fā)。轟動 一時的 HotSpot 熱潮也逐漸淡去。 現(xiàn)在 SUN 再也不怎么提起 HotSpot 編譯器了， 只是在每一個新版本的 JDK中不斷持續(xù)的 改善 HotSpot 的編譯品質(zhì)。想起當(dāng)初 SUN 對 HotSpot不可一世的吹噓最是令人感嘆。不 過 HotSpot也不是一無是處，的確是精進了許多 Java ByteCode的產(chǎn)生品質(zhì)以及 JVM的 執(zhí)行效率，只是沒有達到當(dāng)初 SUN 夸口逼近或是超越 C 語言編譯器品質(zhì)的程度。在目前 狀況下， HotSpot能夠讓 Java 的編譯品質(zhì)在伺服端的效率有著顯著的提升，提供非常 不錯的執(zhí)行效率。但是在客戶端，尤其是牽涉到圖形使用者接口 Render 方面的應(yīng)用時， 仍然是相當(dāng)緩慢的。 就 Borland本身使用 Java 的情形來說， Borland使用 Java開發(fā)的 VisiBroker For Java 的執(zhí)行效率已經(jīng)相當(dāng)接近 VisiBroker For C/C++的執(zhí)行效率。因此如果再搭配使用品 質(zhì)良好的 JVM，那么根據(jù) Borland 內(nèi)部的測試數(shù)據(jù)顯示， VisiBroker For Java 甚至在 一些特定的應(yīng)用中超越了 VisiBroker For C/C++。 HotSpot在紛紛擾擾的這么多年之后到底是不是一些人譏笑的 笑話科技 呢？不同的 人到現(xiàn)在可能還是有不同的答案吧。 Borland的困境和選擇 Open JBuilder雖然趕在 1997 年最末的一班車推出，但在市場上的反映并不如預(yù)期的 好。當(dāng)然這是有許多原因的。首先是 Open JBuilder太晚推出，初期的 Java市場早已 被其他的 Java開發(fā)工具，特別是 Visual Caf233。所占領(lǐng)；第二是 Open JBuilder 急著推 出市場，因此在和其他 Java開發(fā)工具競爭時并沒有什么特別突出的功能、明顯的優(yōu)勢， 競爭力當(dāng)然不夠；第三是 Open JBuilder 于一開始就混合地使用了 Delphi和 Java 程序 代碼，因此 Open JBuilder 激活以及窗體設(shè)計家的反應(yīng)都很緩慢，不像 Visual Caf233。 那種以純 C/C++程序代碼撰寫的 Java 開發(fā)工具反應(yīng)迅速，從而給許多程序員造成了 不良的印象。 IBM的 VisualAge For Java 雖然也很遲緩，但在高階的團隊開發(fā)方面卻 支持得很好，而且通常會使用團隊開發(fā)功能的使用者大都是屬于企業(yè)或是大型用戶， 因此使用的機器配備也很好，對于 VisualAge For Java 的緩慢反應(yīng)也還能夠接受。 Open JBuilder的表現(xiàn)不如預(yù)期，這讓 Borland 很著急，因為其無法承受失去 Java 開 發(fā) 工具市場的損失。因此在 Borland 的 Java開發(fā)工具研發(fā)小組中開始有了一些討論，那 就是如何讓 Open JBuilder 能夠后來居上，取得勝利的果實。針對 Open JBuilder 的失 敗原因， Open JBuilder的開發(fā)人員開始反思是否也應(yīng)該像 Visual Caf233。一樣使用 Delphi重新打造 Open JBuilder，讓 Open JBuilder的執(zhí)行反應(yīng)加快到使用者能夠接受 的地步，因為在當(dāng)時 Borland 實在已經(jīng)無法再加快 Java的執(zhí)行速度。此外使用 Delphi 開發(fā) Open JBuilder 的窗體設(shè)計家也可以避免許多 JDK 的臭蟲，不會因 SUN 開發(fā)或是改 善 JDK 的時程而影響到 Open JBuilder的開發(fā)周期。 這個想法在 Open JBuilder 的內(nèi)部引起了很大的爭議。使用 Delphi重寫 Open JBuilder 的集成開發(fā)環(huán)境可以擁有許多短期的效益而且產(chǎn)品馬上會有明顯的改善，可以擁有和 其他競爭對手一搏的本錢。不過反對的人則認(rèn)為使用原生開發(fā)工具開發(fā) Java的工具是 走回頭路。這些人認(rèn)為 Java有朝一日一定會開發(fā)到成熟的階段，到時 Open JBuilder 就會擁有最后的勝利，現(xiàn) 在只是一時的挫折，沒有必要灰心。 對于 Borland 來說，如何繼續(xù) Open JBuilder是一個困難的抉擇，因為當(dāng)時 Borland急 需收入的挹注，而 Open JBuilder 的研發(fā)費用驚人，光靠 Delphi 力撐實在是很辛苦。 不過如果再回到使用 Delphi開發(fā)，那么可能又會失去未來的機會，這到底應(yīng)該如何決 定呢？ Java 天才的加入 這一切的答案在 Open JBuilder的新產(chǎn)品架構(gòu)領(lǐng)導(dǎo)人 Blake Stone 加入后才逐漸明朗。 Blake Stone 原本是 DSW Systems Corporation 公司的技術(shù)主管，而 DSW 公司一向和 Borland 互動良好，許多 DSW 公司的人都曾在 Borland的 Conference(BorCon)中負(fù)責(zé)技術(shù)講座。 Blake Stone 先生也在 1997年的 BorCon 中負(fù)責(zé)了一個講座。也許是 Blake Stone 和 Borland 在這次的 BorCon 中合作愉快， Borland也很賞識 Blake Stone 的技術(shù)和才華，因此在 BorCon 結(jié)束之后不久， Borland便和 Blake Stone接觸，看看 Blake 是否有意愿加入 Borland 的 Java 研發(fā) 小組。也許是天意吧，在 Borland 失去了 Anders這個天才之后，老天又給了 Borland一個彌補軟件天才的機會。 在 Borland和 Blake 接觸之后， Blake不但對于 Java未來的潛力看好，而且因為 Blake也 曾使用 Delphi，對于 Borland 研發(fā)開發(fā)工具的能力相當(dāng)有信心。更湊巧的是由于 Open JBuilder 的不盡人意，因此此時剛好有一個 Open JBuilder 的 Architect 離職， 讓 Blake 立刻有了適當(dāng)?shù)穆毼?。沒有多久 Blake 便答應(yīng)進入 Borland 作為 JBuilder的 Architect，目的是帶領(lǐng) JBuilder 成為最成功的 Java 開發(fā)工具。由于 Blake驚人的天 分，因此很快就成為 JBuilder 的主要 Architect以及技術(shù)的主領(lǐng)導(dǎo)者， JBuilder 未來 開發(fā)的 Java 技術(shù)都由 Blake負(fù)責(zé)研究和研發(fā)的工作。 Blake 進入 JBuilder開發(fā)小組之后，面臨的第一個挑戰(zhàn)便是如何改造 Open JBuilder， 讓它執(zhí)行得更為順利，并且能夠在競爭群中脫穎而出。當(dāng)然 Blake必須做的第一個抉 擇就是 Open JBuilder 到底該走向純 Java的開發(fā)工 具或是改成原生的 Windows Java 開 發(fā)工具。 Blake并沒有遲疑多久，便決定把 JBuilder帶向純 Java 的開發(fā)工具，使用 Java 語言本身來打造整個 JBuilder。 Blake做了如此的決定是有許多原因的。首先是 Blake 希望通過使用 Java 語言開發(fā) JBuilder本身來讓 Borland 的工程師徹底掌握 Java的技術(shù)， 也希望通過這樣的開發(fā)來證明 Java的實用性。就像 Delphi本身就是使用 Object Pascal 和 Delphi 研發(fā)、 Borland通過 Object Pascal證明了 Delphi 的實用性和可靠性一樣， Blake 也希望使用 JBuilder來證明 Java 語言的可用性。 第 2 點是因為打造純 Java 開發(fā)工具可以讓 JBuilder通過 Java跨平臺的特性把 JBuilder 推向其他所有支持 Java 的平臺，讓 Borland 能夠穿透到以往無法進入的市場，這樣可 以讓 JBuilder的潛在市場和客戶比競爭對手的更寬廣、更多。 第 3 點因素則是 Blake 希望通過這個行動讓 Borland掌握 Java的核心技術(shù)，最好能夠和 SUN 有更密切的互動，讓 Borland 能夠在 Java領(lǐng)域取得相關(guān)的領(lǐng)導(dǎo) 地位。因為在和以往 Microsoft交手的過程中， Borland深深了解到如果無法在一個技術(shù)領(lǐng)域取得第 1或是 第 2 的地位，那么終將成為微不足道的角色，被市場淘汰出局。 Blake 在 JBuilder研發(fā)方向制定的策略事后都被證明是正確的。后來 JBuilder 果然能 夠支持 Windows、 Linux 和 Solaris平臺，成為當(dāng)時架構(gòu)最大、最復(fù)雜的 Java應(yīng)用程序。 更重要的是 SUN 充分肯定了 Borland 在 Java 方面卓越的技術(shù)，進而采用 Borland的 Baja 技術(shù)制定 Java Bean 規(guī)格并且邀請 Borland 共同參與開發(fā) Java的 JDK。 Blake在 JBuilder 早期設(shè)定了成功的趨勢，奠定了 JBuilder成功的基礎(chǔ)。稍后 JBuilder新的產(chǎn)品經(jīng)理 Tony de la Lama 又成功地制訂了 JBuilder 的市場研發(fā)腳步