Java虛擬機(jī)家族考作者 周志明 發(fā)布于 2011年7月26日 
說(shuō)起Java虛擬機(jī)，許多Java程序員都會(huì)潛意識(shí)地把它與Sun[1] HotSpot虛擬機(jī)等同看待，也許還有一些程序員會(huì)注意到BEA JRockit和IBM J9，但大多數(shù)人對(duì)JVM的認(rèn)識(shí)都僅限于此了。 相關(guān)廠商內(nèi)容從1996年初Sun發(fā)布的JDK 1.0中所包含的Sun Classic VM算起，Java虛擬機(jī)已經(jīng)發(fā)展了15個(gè)年頭，滄海桑田一瞬間，15年轉(zhuǎn)眼而過(guò)，這期間曾經(jīng)涌現(xiàn)、湮滅過(guò)許多或經(jīng)典或優(yōu)秀或有特色的虛擬機(jī)實(shí)現(xiàn)，在 《Java虛擬機(jī)專欄》的第1篇中，我們先暫且把代碼與技術(shù)放下，一起來(lái)回顧一下Java虛擬機(jī)家族的發(fā)展軌跡和歷史變遷。 虛擬機(jī)始祖：Sun Classic / Exact VM以今天的視角來(lái)看，Sun Classic VM的技術(shù)可能很原始，這款虛擬機(jī)的使命也早已終結(jié)。但僅憑它 “世界上第一款商用Java虛擬機(jī)”的頭銜，就足夠有令歷史有記住它的理由。 1996年1月23日，Sun發(fā)布JDK 1.0，Java語(yǔ)言首次擁有了商用的正式運(yùn)行環(huán)境，這個(gè)JDK中所帶的虛擬機(jī)就是Classic VM。這款虛擬機(jī)只能使用純解釋器方式來(lái)執(zhí)行Java代碼，如果要使用JIT編譯器那就必須進(jìn)行外掛，但是假如外掛了JIT編譯器，JIT編譯器就完全接 管了虛擬機(jī)的執(zhí)行系統(tǒng)，解釋器便不再工作了。用戶在這款虛擬機(jī)上執(zhí)行java –version命令，將會(huì)看到類似下面這行的輸出： java version "1.2.2" Classic VM (build JDK-1.2.2-001, green threads, sunwjit) 其中的“sunwjit”就是Sun提供的外掛編譯器，其他類似的外掛編譯器還有Symantec JIT和shuJIT等。由于解釋器和編譯器不能配合工作，這就意味著如果要使用編譯器執(zhí)行，編譯器就不得不為對(duì)每一個(gè)方法，每一行代碼都進(jìn)行編譯，而無(wú) 論它們執(zhí)行的頻率是否具有編譯的價(jià)值?；诔绦蝽憫?yīng)時(shí)間的壓力，這些編譯器根本不敢應(yīng)用編譯耗時(shí)稍高的優(yōu)化技術(shù)，因此這個(gè)階段的虛擬機(jī)即使用了JIT編譯 器輸出本地代碼，執(zhí)行效率也和傳統(tǒng)的C/C++程序有很大差距，“Java語(yǔ)言很慢”的形象就是在這時(shí)候開始在用戶心中樹立起來(lái)的。 Sun的虛擬機(jī)團(tuán)隊(duì)努力去解決Classic VM所面臨的各種問(wèn)題，提升運(yùn)行效率，在JDK 1.2時(shí)，曾在Solaris平臺(tái)上發(fā)布過(guò)一款名為Exact VM的虛擬機(jī)，它的執(zhí)行系統(tǒng)已經(jīng)具備現(xiàn)代高性能虛擬機(jī)雛形：如兩級(jí)即時(shí)編譯器、編譯器與解釋器混合工作模式等。Exact VM因它使用準(zhǔn)確式內(nèi)存管理（Exact Memory Management，也可以叫Non-Conservative/Accurate Memory Management）而得名，即虛擬機(jī)可以知道內(nèi)存中某個(gè)位置的數(shù)據(jù)具體是什么類型。譬如內(nèi)存中有一個(gè)32bit的整數(shù)123456，它到底是一個(gè) reference類型指向123456的內(nèi)存地址還是一個(gè)數(shù)值為123456的整數(shù)，虛擬機(jī)將有能力分辨出來(lái)，這樣才能在GC的時(shí)候準(zhǔn)確判斷堆上的數(shù)據(jù) 是否還可能被使用。由于使用了準(zhǔn)確式內(nèi)存管理，Exact VM可以拋棄掉以前Classic VM基于handler的對(duì)象查找方式（原因是GC后對(duì)象將可能會(huì)被移動(dòng)位置，如果地址為123456的對(duì)象移動(dòng)到654321，在沒(méi)有明確信息表明內(nèi)存 中哪些數(shù)據(jù)是reference的前提下，那虛擬機(jī)是不敢把內(nèi)存中所有為123456的值改成654321的，所以要使用句柄來(lái)保持reference值 的穩(wěn)定），這樣每次定位對(duì)象都少了一次間接查找的開銷，提升執(zhí)行性能。 雖然Exact VM的技術(shù)相對(duì)Classic VM來(lái)說(shuō)先進(jìn)了許多，但是它命運(yùn)顯得十分英雄氣短，在商業(yè)應(yīng)用上只存在了很短暫的時(shí)間就被更為優(yōu)秀的HotSpot VM所取代，甚至還沒(méi)有來(lái)得及發(fā)布Windows和Linux平臺(tái)下的商用版本。而Classic VM的生命周期則相對(duì)長(zhǎng)了許多，它在JDK 1.2之前是Sun JDK中唯一的虛擬機(jī)，在JDK 1.2時(shí)，它與HotSpot VM并存，但默認(rèn)是使用Classic VM（用戶可用java –hotspot參數(shù)切換至HotSpot VM），而在JDK 1.3時(shí)，HotSpot VM成為默認(rèn)虛擬機(jī)，它仍作為虛擬機(jī)的“備用選擇”發(fā)布（使用java –classic參數(shù)切換），直到JDK 1.4的時(shí)候，Classic VM才正式退出商用虛擬機(jī)的歷史舞臺(tái)，與Exact VM一起進(jìn)入了Sun Labs Research VM之中。 武林盟主：Sun HotSpot VMHotSpot VM相信所有Java程序員都知道，它是Sun JDK和OpenJDK中所帶的虛擬機(jī)，也是目前使用范圍最廣的Java虛擬機(jī)。但不一定所有人都知道的是，這個(gè)目前看起來(lái)“血統(tǒng)純正”的虛擬機(jī)在最初并 非由Sun公司開發(fā)，而是由一家名為“Longview Technologies”的小公司設(shè)計(jì)的；甚至這個(gè)虛擬機(jī)最初并非是為Java語(yǔ)言而開發(fā)的，它來(lái)源于Strongtalk語(yǔ)言，而虛擬機(jī)中相當(dāng)多的技 術(shù)又是來(lái)源于一款支持Self語(yǔ)言實(shí)現(xiàn)“達(dá)到C語(yǔ)言50%以上的執(zhí)行效率”的目標(biāo)而設(shè)計(jì)的虛擬機(jī)，Sun公司注意到了這款虛擬機(jī)在JIT編譯上有許多優(yōu)秀 的理念和實(shí)際效果，在1997年收購(gòu)了Longview Technologies公司，從而獲得了HotSpot VM。 HotSpot VM既繼承了Sun之前兩款商用虛擬機(jī)的優(yōu)點(diǎn)（如前面提到的準(zhǔn)確式內(nèi)存管理），也有許多自己新的技術(shù)優(yōu)勢(shì)，如它名稱中的HotSpot指的就是它的熱點(diǎn)代 碼探測(cè)技術(shù)（其實(shí)Exact VM之中也有與HotSpot幾乎一樣的熱點(diǎn)探測(cè)，為了Exact VM和HotSpot VM哪個(gè)成為Sun主要支持的產(chǎn)品VM，在Sun公司內(nèi)部還大吵過(guò)一場(chǎng)，HotSpot打敗Exact并不能算技術(shù)上的勝利），HotSpot VM的熱點(diǎn)代碼探測(cè)能力可以通過(guò)執(zhí)行計(jì)數(shù)器找出最具優(yōu)編譯價(jià)值的代碼，然后通知JIT編譯器以方法為單位進(jìn)行編譯。如果一個(gè)方法被頻繁調(diào)用，或方法中回邊 （回邊是指程序向后跳轉(zhuǎn)的行為）次數(shù)很多，將會(huì)分別觸發(fā)標(biāo)準(zhǔn)編譯和OSR（棧上替換）編譯動(dòng)作。通過(guò)編譯器與解釋器恰當(dāng)?shù)貐f(xié)同工作，可以在最優(yōu)化的程序響 應(yīng)時(shí)間與最佳執(zhí)行性能中取得平衡，而且無(wú)需等待本地代碼輸出才能執(zhí)行程序，即時(shí)編譯的時(shí)間壓力也相對(duì)減小，這樣有助于引入更多的代碼優(yōu)化技術(shù)，輸出質(zhì)量更 高的本地代碼。 2006年的JavaOne大會(huì)上，Sun宣布最終會(huì)把Java開源，并在隨后的一年，陸續(xù)地將JDK的各個(gè)部分（其中當(dāng)然也包括了HotSpot VM）在GPL協(xié)議下公開了源碼，并在此基礎(chǔ)上建立了OpenJDK。這樣，HotSpot VM便成為了Sun JDK和OpenJDK兩個(gè)實(shí)現(xiàn)極度接近的JDK項(xiàng)目的共同虛擬機(jī)。 在2008年和2010年，Oracle分別收購(gòu)了BEA和Sun公司，這樣Oracle就同時(shí)擁有了這個(gè)星球上最優(yōu)秀的兩款Java虛擬 機(jī)：JRockit VM和HotSpot VM。Oracle宣布在不久的將來(lái)（大約應(yīng)在JDK 8的時(shí)候）會(huì)完成這兩款虛擬機(jī)的整合工作，使之優(yōu)勢(shì)互補(bǔ)。整合的方式大致上是在HotSpot的基礎(chǔ)上，移植JRockit的優(yōu)秀特性，譬如使用 JRockit的垃圾回收器與MissionControl服務(wù)，使用HotSpot的JIT編譯器與混合的運(yùn)行時(shí)系統(tǒng)。當(dāng)HotSpot吸收了 JRockit的全部功力之后，能否一統(tǒng)虛擬機(jī)的江湖，成為真正的武林盟主，我們拭目以待。 小數(shù)派：Sun Mobile-Embedded VM / Meta-Circular VMSun公司所研發(fā)的虛擬機(jī)可不僅有前面介紹到的服務(wù)器、桌面領(lǐng)域的商用虛擬機(jī)，除此之外，Sun面對(duì)移動(dòng)和嵌入式市場(chǎng)，也發(fā)布過(guò)虛擬機(jī)產(chǎn)品，另外還 有一類虛擬機(jī)，在設(shè)計(jì)之初就沒(méi)有抱著商用的目的，僅僅是用于研究、驗(yàn)證某種技術(shù)和觀點(diǎn)，又或者是作為一些規(guī)范的標(biāo)準(zhǔn)實(shí)現(xiàn)。這些虛擬機(jī)對(duì)于大部分不從事相關(guān) 領(lǐng)域開發(fā)的Java程序員來(lái)說(shuō)可能比較陌生，Sun公司發(fā)布的其他Java虛擬機(jī)有：
KVM中的K是“Kilobyte”的意思，它強(qiáng)調(diào)簡(jiǎn)單，輕量，高度可移植，但是運(yùn)行速度比較慢。在Androd、iOS等智能手機(jī)操作系統(tǒng)出現(xiàn)前曾經(jīng)在手機(jī)平臺(tái)上得到非常廣泛應(yīng)用。 CDC/CLDC全稱是Connected（Limited）Device Configuration，在JSR-139/JSR-218規(guī)范中進(jìn)行定義，它希望在手機(jī)、電子書、PDA等設(shè)備上建立統(tǒng)一的Java編程接口，而 CDC HotSpot VM和CLDC HotSpot VM則是它們的一組參考實(shí)現(xiàn)。CDC/CLDC是整個(gè)Java ME的重要支柱，但從目前Android和Apple iOS二分天下的移動(dòng)數(shù)字設(shè)備市場(chǎng)看來(lái)，在這個(gè)領(lǐng)域中，Sun的虛擬機(jī)所面臨的局面遠(yuǎn)不如服務(wù)器和桌面領(lǐng)域樂(lè)觀。 Squawk VM是由Sun開發(fā)，運(yùn)行于Sun SPOT（Sun Small Programmable Object Technology，一種手持的Wifi設(shè)備），也曾經(jīng)運(yùn)用于Java Card。這是一個(gè)Java代碼比重很高的嵌入式虛擬機(jī)實(shí)現(xiàn)，其中諸如類加載器、字節(jié)碼驗(yàn)證器、垃圾收集器、解釋器、編譯器和線程調(diào)度都是Java語(yǔ)言本 身所完成的，僅僅靠C語(yǔ)言來(lái)編寫設(shè)備I/O和必要的本地代碼。 JavaInJava是Sun公司1997年～1998年間所研發(fā)的一個(gè)實(shí)驗(yàn)室性質(zhì)的虛擬機(jī)，從名字就可以看出，它試圖以Java語(yǔ)言來(lái)實(shí) 現(xiàn)Java語(yǔ)言本身的運(yùn)行環(huán)境，既所謂的“元循環(huán)”（Meta-Circular，是指使用語(yǔ)言自身來(lái)實(shí)現(xiàn)其運(yùn)行環(huán)境）。它必須運(yùn)行在另外一個(gè)宿主虛擬機(jī) 之上，內(nèi)部沒(méi)有JIT編譯器，代碼只能以解釋模式執(zhí)行。在上世紀(jì)末主流Java虛擬機(jī)都未能很好解決性能問(wèn)題的時(shí)代，開發(fā)這種項(xiàng)目，其執(zhí)行速度大家可想而 知。 Maxine VM和上面的JavaInJava非常相似，它也是一個(gè)幾乎全部以Java代碼實(shí)現(xiàn)（只有用于啟動(dòng)JVM的加載器使用C語(yǔ)言編寫）的元循環(huán)Java虛擬 機(jī)。這個(gè)項(xiàng)目于2005年開始，到現(xiàn)在仍然在發(fā)展之中，比起JavaInJava，Maxine VM就顯得“靠譜”很多，它有先進(jìn)的JIT編譯器和垃圾收集器（但沒(méi)有解釋器），可在宿主模式或獨(dú)立模式下執(zhí)行，其執(zhí)行效率已經(jīng)接近了HotSpot Client VM的水平。 百家爭(zhēng)鳴：BEA JRockit / IBM J9 VM前面介紹了Sun公司的各種虛擬機(jī)，除了Sun公司以外，其他組織、公司也研發(fā)過(guò)不少虛擬機(jī)實(shí)現(xiàn)，其中規(guī)模最大、最著名的就是BEA和IBM公司了。 JRockit VM曾經(jīng)號(hào)稱“世界上速度最快的Java虛擬機(jī)”（廣告詞，貌似J9 VM也這樣說(shuō)過(guò)），它是BEA公司在2002年從Appeal Virtual Machines公司收購(gòu)獲得的虛擬機(jī)。BEA將其發(fā)展為一款專門為服務(wù)器硬件和服務(wù)端應(yīng)用場(chǎng)景高度優(yōu)化的虛擬機(jī)，由于專注于服務(wù)端應(yīng)用，它可以不太關(guān)注 于程序啟動(dòng)速度，因此JRockit內(nèi)部不包含解析器實(shí)現(xiàn)，全部代碼都靠即時(shí)編譯器編譯后執(zhí)行。除此之外，JRockit的垃圾收集器和 MissionControl服務(wù)套件等部分的實(shí)現(xiàn)，在眾多Java虛擬機(jī)中也一直處于領(lǐng)先水平。 IBM J9 VM并不是IBM公司唯一的Java虛擬機(jī)，不過(guò)是目前IBM主力發(fā)展的Java虛擬機(jī)，J9原本是內(nèi)部開發(fā)代號(hào)，正式名稱是“IBM Technology for Java Virtual Machine”，簡(jiǎn)稱IT4J，只是這個(gè)名字太拗口了一點(diǎn)，普及程度不如J9。J9 VM最初是由IBM Ottawa實(shí)驗(yàn)室一個(gè)SmallTalk的虛擬機(jī)擴(kuò)展而來(lái)的，當(dāng)時(shí)這個(gè)虛擬機(jī)有一個(gè)bug是因?yàn)?k值定義錯(cuò)誤引起，工程師們花了很長(zhǎng)時(shí)間終于發(fā)現(xiàn)并解 決了這個(gè)錯(cuò)誤，此后這個(gè)版本的虛擬機(jī)就被稱為K8了，后來(lái)擴(kuò)展出支持Java的虛擬機(jī)就被稱為J9了。與BEA JRockit專注于服務(wù)端應(yīng)用不同，IBM J9的市場(chǎng)定位與Sun HotSpot比較接近，它是一款設(shè)計(jì)上從服務(wù)端到桌面應(yīng)用再到嵌入式都全面考慮的多用途虛擬機(jī)，J9的開發(fā)目的是作為IBM公司各種Java產(chǎn)品的執(zhí)行 平臺(tái)，它的主要市場(chǎng)在和IBM產(chǎn)品（如IBM WebSphere等）搭配以及在IBM AIX和z/OS這些平臺(tái)上部署Java應(yīng)用。 除了BEA和IBM外，其他一些大公司如HP、SAP等也號(hào)稱有自己的專屬JDK和虛擬機(jī)，但是它們是通過(guò)從Sun購(gòu)買版權(quán)的方式獲得的，并非自己獨(dú)立開發(fā)。 最終兵器：Azul VM/BEA Liquid VM我們平時(shí)所提及的“高性能Java虛擬機(jī)”一般是指HotSpot、JRockit、J9這類在通用平臺(tái)上運(yùn)行的商用虛擬機(jī)，但其實(shí)Azul VM和BEA Liquid VM這類特定硬件平臺(tái)專有的虛擬機(jī)才是“高性能”的最終兵器。 Azul VM是Azul Systems 公司在HotSpot基礎(chǔ)上進(jìn)行大量改進(jìn)，運(yùn)行于Azul Systems 公司的專有硬件Vega系統(tǒng)上的Java虛擬機(jī)，每個(gè)Azul VM實(shí)例都可以管理至少數(shù)十個(gè)CPU和數(shù)百GB的內(nèi)存的硬件資源，并提供在巨大內(nèi)存范圍內(nèi)實(shí)現(xiàn)可控的GC時(shí)間的垃圾收集器、為專有硬件優(yōu)化的線程調(diào)度等優(yōu) 秀特性。在2010年，Azul開始從硬件轉(zhuǎn)向軟件，發(fā)布了自己的Zing JVM，可以在通用x86平臺(tái)上提供接近于Vega系統(tǒng)的特性。 Liquid VM是BEA公司開發(fā)的，可以直接運(yùn)行在自家Hypervisor系統(tǒng)上的JRockit VM的虛擬化版本，Liquid VM不需要操作系統(tǒng)的支持，或者說(shuō)它自己本身實(shí)現(xiàn)了一個(gè)專用操作系統(tǒng)的必要功能，如文件系統(tǒng)、網(wǎng)絡(luò)支持等。由虛擬機(jī)越過(guò)通用操作系統(tǒng)直接控制硬件可以獲得 很多好處，如在線程調(diào)度時(shí)，不需要再進(jìn)行內(nèi)核態(tài)/用戶態(tài)的切換等，這樣可以最大限度地發(fā)揮硬件的能力，提升Java程序的執(zhí)行性能。 挑戰(zhàn)者：Apache Harmony / Google Android Dalvik VM這節(jié)介紹的Harmony VM和Dalvik VM只能稱作“虛擬機(jī)”，而不能稱作“Java虛擬機(jī)”，但是這兩款虛擬機(jī)（以及所代表的技術(shù)體系）對(duì)最近三年的Java世界產(chǎn)生了非常大的影響和挑戰(zhàn)，甚至有悲觀的評(píng)論家認(rèn)為成熟的Java生態(tài)系統(tǒng)有崩潰的可能。 Apache Harmony是一個(gè)Apache軟件基金會(huì)旗下以Apache License協(xié)議開源的實(shí)際兼容于JDK 1.5和JDK 1.6的Java程序運(yùn)行平臺(tái)，這個(gè)介紹相當(dāng)拗口。它包含自己的虛擬機(jī)和Java庫(kù)，用戶可以在上面運(yùn)行Eclipse、Tomcat、Maven等常見(jiàn) 的Java程序，但是……它沒(méi)有通過(guò)TCK認(rèn)證，所以我們不得不用那么一長(zhǎng)串拗口的語(yǔ)言來(lái)介紹它，而不能用一句“Apache的JDK”來(lái)說(shuō)明。如果一個(gè) 公司要宣布自己的運(yùn)行平臺(tái)“兼容于Java語(yǔ)言”，那就必須要通過(guò)TCK（Technology Compatibility Kit）的兼容性測(cè)試，Apache基金會(huì)曾要求Sun公司提供TCK的使用授權(quán)，但是一直遭到拒絕，直到Oracle收購(gòu)了Sun公司之后，雙方關(guān)系越 鬧越僵，最終導(dǎo)致Apache憤然退出JCP（Java Community Process）組織，這是近代Java社區(qū)最嚴(yán)重的一次分裂。 在Sun把JDK開源形成OpenJDK之后，Apache Harmony開源的優(yōu)勢(shì)被極大地削弱，甚至連Harmony項(xiàng)目的最大參與者IBM公司也宣布辭去Harmony項(xiàng)目管理主席的職位，參與 OpenJDK項(xiàng)目的開發(fā)。雖然Harmony沒(méi)有真正大規(guī)模商業(yè)運(yùn)用過(guò)，但是它的許多代碼（基本上是Java庫(kù)部分的代碼）被吸納進(jìn)IBM的JDK7實(shí) 現(xiàn)以及Google Android SDK之中，尤其是對(duì)Android的發(fā)展起了很大推動(dòng)作用。 說(shuō)到Android，這個(gè)時(shí)下最熱門的移動(dòng)數(shù)碼設(shè)備平臺(tái)在最近3年間的發(fā)展所取得的成果已經(jīng)遠(yuǎn)遠(yuǎn)超越了Java ME在過(guò)去十多年所獲得的成果，Android讓Java語(yǔ)言真正走進(jìn)了移動(dòng)數(shù)碼設(shè)備領(lǐng)域，只是走的并非Sun公司原本想象的那一條路。 Dalvik VM是Android平臺(tái)的核心組成部分之一，它名字來(lái)源于冰島一個(gè)名為Dalvik的小漁村。Dalvik VM并不是一個(gè)Java虛擬機(jī)，它沒(méi)有遵循Java虛擬機(jī)規(guī)范，不能直接執(zhí)行Java的class文件，使用寄存器架構(gòu)而不是JVM中常見(jiàn)的棧架構(gòu)。但是 它與Java卻又有著千絲萬(wàn)縷的聯(lián)系，它執(zhí)行dex（Dalvik Executable）文件可以通過(guò)class文件轉(zhuǎn)化而來(lái)，使用Java語(yǔ)法編寫應(yīng)用程序，可以直接使用大部分的Java API等等。目前Dalvik VM隨著Android一起處于迅猛發(fā)展階段，在Android 2.2中已提供即時(shí)編譯器實(shí)現(xiàn)，執(zhí)行性能有了很大的提高。 沒(méi)有成功，但并非失?。篗ircosoft JVM及其他在十幾年的Java虛擬機(jī)發(fā)展歷程中，除去上面介紹那些被大規(guī)模商業(yè)應(yīng)用過(guò)的Java虛擬機(jī)外，還有許多虛擬機(jī)是不為人知或者曾經(jīng)絢麗過(guò)但最終湮滅的。我們以其中Mircorsoft公司的JVM來(lái)介紹一下。 也許Java程序員聽起來(lái)可能會(huì)覺(jué)得驚訝，微軟曾經(jīng)是Java技術(shù)的鐵桿支持者。在Java語(yǔ)言誕生的初期（1996年～1998年，以 JDK1.2發(fā)布之前為分界），它的主要的應(yīng)用之一是在瀏覽器中運(yùn)行Java Applets程序，微軟為了在IE3中支持Java Applets應(yīng)用而開發(fā)了自己的Java虛擬機(jī)，雖然這款虛擬機(jī)只有Windows平臺(tái)的版本（這很正常吧？），但卻是當(dāng)時(shí)Windows下性能最好的 Java虛擬機(jī)，它在1997和1998連續(xù)兩年獲得了《PC Magazine》雜志的“編輯選擇獎(jiǎng)”。但好景不長(zhǎng)，在1997年10月，Sun公司正式以侵犯商標(biāo)、不正當(dāng)競(jìng)爭(zhēng)等罪名控告微軟，在隨后對(duì)微軟公司的壟 斷調(diào)查之中，這款虛擬機(jī)也曾作為證據(jù)之一被呈送法庭。這場(chǎng)官司的結(jié)果是微軟賠償2000萬(wàn)美金給Sun，承諾終止其Java虛擬機(jī)的發(fā)展，并逐步在產(chǎn)品中 移除Java虛擬機(jī)相關(guān)功能。 我們?cè)囅胍幌拢绻?dāng)年Sun沒(méi)有起訴微軟公司，微軟繼續(xù)保持著對(duì)Java技術(shù)的熱情，那Java的世界會(huì)變得更好還是更壞？.NET技術(shù)是否會(huì)發(fā)展起來(lái)？但歷史是沒(méi)有如果的。其他在本文中沒(méi)有介紹到的Java虛擬機(jī)還包括有（當(dāng)然，應(yīng)該還有很多筆者所不知道的）：
參考資料本文撰寫時(shí)主要參考了以下資料：
[1] Sun與BEA分別在2010、2008年被Oracle公司收購(gòu)，由于本文涉及到大量歷史事件，為了避免混亂，依然保留Sun和BEA的名稱。 |
|
|
來(lái)自： daomucun > 《技術(shù)積累》
