首先是對JAVA 和 .NET平臺的構(gòu)成做一個(gè)分析，然后是我個(gè)人對JAVA如何形成的一個(gè)認(rèn)識，接著是分析微軟和SUN
之間的合作與分歧，最后是JAVA與.NET合作的前景。

我個(gè)人強(qiáng)烈認(rèn)為JAVA與.NET將在不久的未來逐步的統(tǒng)一起來。已經(jīng)有很多關(guān)于整合JAVA和.NET的項(xiàng)目計(jì)劃被提交到源碼開
放組織。在微軟的MSDN，SUN 的JAVA站點(diǎn)，以及來自于ECMA 和 W3C.org的標(biāo)準(zhǔn)文檔都可以看到有關(guān)內(nèi)容。

簡介

JAVA與.NET繼續(xù)發(fā)展下去，可能的兩種結(jié)果：其中的一種退出競爭或是兩種共存，而共存的可能性更大。JAVA得以生
存的原因在于它的時(shí)間優(yōu)勢：它已經(jīng)發(fā)展了六年；它在大多數(shù)的操作系統(tǒng)上可以運(yùn)行；它得到了業(yè)界領(lǐng)導(dǎo)者如ORACLE、IBM
的支持；并且使用JAVA進(jìn)行開發(fā)的項(xiàng)目計(jì)劃幾乎覆蓋所有的應(yīng)用程序領(lǐng)域。

而.NET的優(yōu)勢在于微軟擁有90%的桌面操作系統(tǒng)市場，同時(shí)微軟也開始采用SUN的市場戰(zhàn)略，即將其特有的技術(shù)標(biāo)準(zhǔn)
化。如：在遠(yuǎn)程通信上它向IETF（InternetEngineering Task Force）和W3C（World Wide Web Consortium）提交了SOAP
（SIMPLE OBJECT ACCESS PROTOCLE）（類似于RFC-REQUEST FORCOMMENT）；向ECMA (European Computer
Manufacturer's Association)提交了C#語言和通用運(yùn)行時(shí)（COMMON RUNTIME）基礎(chǔ)結(jié)構(gòu)的標(biāo)準(zhǔn)。

JAVA平臺的構(gòu)架

JAVA平臺包括JAVA語言，以及一套虛擬機(jī)——如JVM、KVM、CVM等——通過它們實(shí)現(xiàn)在PC機(jī)，手提電腦或是嵌入式系
統(tǒng)上運(yùn)行JAVA的字節(jié)碼。同時(shí)，JAVA平臺還定義了一整套覆蓋面很廣的API，它們被用來與微軟的API協(xié)調(diào)或是相互競爭。
如JDBC對ODBC，JTAPI對TAPI，JDO對ADO等等。因此，簡要來說，JAVA平臺包括語言，虛擬機(jī)，以及API庫。

由于使用虛擬機(jī)機(jī)制，所以JAVA語言在所有的平臺上只有唯一的版本，因此它使用RMI（遠(yuǎn)程方法調(diào)用Remote
Method Invocation）協(xié)議進(jìn)行遠(yuǎn)程通信；微軟則在.NET框架中使用DCOM——正在逐步演變?yōu)镾OAP（簡單對象訪問協(xié)議）。

SUN最初對JAVA的宣傳是“一次性代碼編寫，所有環(huán)境下運(yùn)行”，但在推出了“J2EE” (Java 2 Enterprise
Edition)和“J2ME” (Java 2 Micro Edition)后不得不收回了它最初的宣傳，因?yàn)椤耙环N尺碼的鞋適合所有的腳”的解決
方案并不能很好的工作。

.NET平臺的構(gòu)架

.NET框架包括C++, VB.NET (VB 7.x) 和 C# 等一系列語言；與JAVA虛擬機(jī)類似的一套運(yùn)行時(shí)環(huán)境；以及一套傾向與
WINDOWS體系的API接口。其中的運(yùn)行時(shí)環(huán)境可能存在于一個(gè)瀏覽器、或是一個(gè)WEB SERVER、或是在操作系統(tǒng)中。將來也許
在SQL SERVER中也可能存在這樣的運(yùn)行時(shí)環(huán)境。另外需要提及的是微軟的SOAP協(xié)議，它在繼承了DCOM的一些特性的基礎(chǔ)上
發(fā)展起來，基于XML格式通過HTTP進(jìn)行傳輸。SOAP的JAVA版本，可以在http://xml.apache.org上看到它的有關(guān)文檔。

發(fā)展歷程

JAVA最初來源于SUN的一套為機(jī)頂盒設(shè)計(jì)的語言，當(dāng)時(shí)的名字是OAK，SUN將之更名，并將它放在INTERNET上作為開放源碼共
享。隨著專門為網(wǎng)頁設(shè)計(jì)的JAVA APPLET的出現(xiàn)，JAVA語言迅速在INTERNET上流行起來。當(dāng)時(shí)的瀏覽器主要是NETSCAPE。當(dāng)
微軟發(fā)現(xiàn)明天市場的主宰可能是瀏覽器而不是桌面系統(tǒng)時(shí)，開始著手對NETSCAPE進(jìn)行收購，在收購計(jì)劃失敗后微軟發(fā)展了
自己的瀏覽器IE。

當(dāng)時(shí)的INTERNET需要一種語言，而JAVA適時(shí)的出現(xiàn)了，由于它與C++的許多相似的語法，使得很多程序員轉(zhuǎn)向了JAVA。而它
確實(shí)具有很多優(yōu)勢，以至于在98年秋，它的反對者微軟在MSDN中都宣稱，JAVA是編寫COM組件的最佳語言。

隨著JAVA一起出現(xiàn)的還有LINUX操作系統(tǒng)和APACHE服務(wù)器。這三者的聯(lián)合在服務(wù)器端的應(yīng)用表現(xiàn)出強(qiáng)大的威力，以至
WINDOWS NT在企業(yè)級服務(wù)器市場受到了很大的沖擊。

98年出現(xiàn)的DHTML和JAVASCRIPT導(dǎo)致了JAVA APPLET在網(wǎng)頁設(shè)計(jì)領(lǐng)域的淡出，在這里有兩方面因素：一、大部分APPLET效果
現(xiàn)在都可以由DHTML完成；二、而DHTML對帶寬的要求更低。但是JAVA因?yàn)樵诜?wù)器端的應(yīng)用仍有市場，而得以繼續(xù)發(fā)展。
這是開發(fā)源碼的支持者為JAVA添加了活力，首先是APACHE提出的SERVERLET 和 稍后出現(xiàn)的JSP，這些在.com網(wǎng)站的程序開
發(fā)中占據(jù)了一席之地。

JAVA平臺首先以SERVERLET，然后是JSP，最后是EJB(Enterprise Java Beans)，逐步向企業(yè)級應(yīng)用拓展。EJB是一個(gè)面向?qū)?BR>象的事務(wù)進(jìn)程系統(tǒng)，有些類似于微軟的MTS（Microsoft Transaction Server）。事實(shí)上MTS和EJB都不是很成功，因?yàn)樗鼈?BR>都無法達(dá)到INTERNET應(yīng)用的規(guī)模。

就我的觀點(diǎn)來看，JAVA最失敗的時(shí)刻是，SUN通過法律手段向微軟索賠$2000萬，并獲得成功的時(shí)候。微軟從那時(shí)開始
制訂自己的.NET計(jì)劃，同時(shí)也宣布了JAVA作為獨(dú)一無二的INTERNET 平臺的地位的結(jié)束。

展望

現(xiàn)在，我們能看到到還只是一個(gè)很混亂的局面。而在未來，我們將看到.NET的成熟，以及它和JAVA的融合。

JAVA將繼續(xù)保持它的特點(diǎn)：跨平臺的服務(wù)器端應(yīng)用，如WAP服務(wù)器，或者是電信領(lǐng)域的如JAIN(Java API for Intelligent
Networks，同時(shí)它在嵌入式系統(tǒng)中將繼續(xù)保持它的優(yōu)勢，象智能卡、移動電話、PDA等。而我們還將看到.NET的成熟，當(dāng)然
這種成熟需要時(shí)間，可能是相當(dāng)長的一段時(shí)間，就好象當(dāng)年JAVA成長那樣。

ORACLE 8i 及其更老一些的版本，充當(dāng)著一個(gè)JAVA 運(yùn)行時(shí)的載體的角色，這使得JAVA 得以與ORACLE 數(shù)據(jù)庫引擎緊密結(jié)
合；同樣，.NET體系也會與新版本的SQL SERVER，緊密的結(jié)合，這將包括一個(gè)VES （虛擬執(zhí)行系統(tǒng)）執(zhí)行引擎。這將使程
序開發(fā)人員可以在SQL 語句和存儲過程中嵌入C#和VB.NET 的成分。目前，你可以通過調(diào)用DLL函數(shù)來使用擴(kuò)展存儲過程，
但數(shù)據(jù)庫本身并沒有一個(gè)面向?qū)ο蟮倪\(yùn)行時(shí)引擎與之相匹配。

未來的標(biāo)志.NET 成熟的里程碑

非微軟產(chǎn)品，包括服務(wù)器，桌面或是便攜式設(shè)備的操作系統(tǒng)如Solaris, Linux和Palm OS的.NET接口。與JAVA核心的整合。
比如說，針對CLI（Common Language Infrastructure）的JAVA編譯器，針對JAVA虛擬機(jī)的C#編譯器。SQL SERVER 或是
ORACLE 等數(shù)據(jù)庫產(chǎn)品中整合的VES 引擎。由中立的第三方開發(fā)的開放源碼的，完善的.NET平臺。

可以預(yù)見到，微軟將會贊助一些開放源碼的項(xiàng)目，以使.NET 向UNIX 平臺擴(kuò)展，而這將有助于一些開放源碼組織減少它們
對JAVA的偏愛。

JAVA的命運(yùn)

JAVA的一個(gè)主要目標(biāo)是通信設(shè)備提供商，如NOKIA就在它的WAP SERVER 應(yīng)用了JAVA。類似于70年代和80年代初，PC銷
售時(shí)硬件供應(yīng)商將最終的應(yīng)用程序綁定在操作系統(tǒng)中一起銷售，JAVA現(xiàn)在也被綁定于通信設(shè)備中被銷售。

它的另一個(gè)主要方向是JAIN（Java API for Advanced Intelligent Network），它主要是定義一套與協(xié)議（如CDMA，
GSM，IMT2000）無關(guān)的API，以便于基于開放市場的組件開發(fā)。這使得ISV（獨(dú)立軟件供應(yīng)商）可以以插件的形式提供通信
服務(wù)，如可自動轉(zhuǎn)接至最近的可撥通的國際呼叫中心的800免費(fèi)電話。當(dāng)然，JAIN也遇到了對手，想微軟和不列顛通信提出
的Parlay計(jì)劃——它也被業(yè)界所支持。

另外，JAVA在嵌入式設(shè)備中也保持著領(lǐng)先的地位，如smart 3G 和 GPRS，在這里的移動電話系統(tǒng)采用的是J2ME（Java 2
Micro Edition），但是如果它不能很好的解決一些固有的問題，如載入時(shí)的延遲等，也許，很快，它就將被C#代替，如
果.NET 能提供快速的運(yùn)行環(huán)境，和廣泛的業(yè)界支持。

.NET和JAVA的整合

無論從商業(yè)角度，還是開發(fā)者角度，甚至是源碼開放組織的角度，.NET和JAVA的整合都顯得很有必要，下面就二者的整合
做出一個(gè)提前的估計(jì)（所有的相關(guān)項(xiàng)目被分為A、B、C三個(gè)組，以便于看清它們之間的關(guān)系，當(dāng)然這些項(xiàng)目也完全可以被獨(dú)
立的操作）：

JVM to CIL compiler (Group A)

Java API bridge for .NET API and lib. (Group A)

Java compiler for CLI (Group A)

CLI ports for Palm OS, Linux and Solaris (Group B)

.NET API and lib. bridge for Palm OS API (Group B)

.NET API and lib. bridge for POSIX (Group B)

CIL compiler to JVM (Group C)

.NET API and lib. bridge for Java API (Group C)

C# compiler for JVM (Group C)

A組的項(xiàng)目

該組項(xiàng)目的主要目的是使現(xiàn)有的JAVA二進(jìn)制代碼能夠在.NET平臺上被執(zhí)行。這意味著JAVA的二進(jìn)制碼（后綴為class
的文件）不用再從源代碼進(jìn)行重編譯就能運(yùn)行于.NET 平臺了。當(dāng)然這些class 文件在安裝或執(zhí)行時(shí)會被編譯，就好象微軟
的運(yùn)行時(shí)和JIT對微軟中間語言所做的那樣。

JVM to CIL compiler

一個(gè)編譯器，輸入JAVA字節(jié)碼，輸出MSIL代碼——它將被編譯為可執(zhí)行文件（如EXE，DLL，MSI等）

Java API bridge for .NET API and lib

在這里，JAVA API 與每一個(gè)相應(yīng) .NET API之間將建立一個(gè)映射，比如Java API中的java.io.File將被映射到 .NET的
System.IO.File 類。相對于比較簡單的IO類的映射，還有一些映射比較復(fù)雜，比如java.net包到.NET 的SYSTEM.NET的映
射。這里存在的一個(gè)問題是：該項(xiàng)工作如果在C#中進(jìn)行開發(fā)會比較方便。而假如在JAVA中實(shí)現(xiàn)，則需要有一個(gè)直接指向CLI
（Common Language Interface）的編譯器，它能生成符合CLS（Common Language Specification）標(biāo)準(zhǔn)的CIL（Common
Intermediate Language）代碼。

可以通過編寫一個(gè)向?qū)降墓ぞ邅肀苊庖恍┈嵉墓ぷ?，例如，可以利用C# 或JAVA來編寫一個(gè)基于XML格式的對象描述，
用它生成一個(gè)框架代碼，然后根據(jù)需要向其中手寫添加其他代碼。如果你確實(shí)打算進(jìn)行這樣的操作，在
http://xml.apache.org站點(diǎn)你可以找到很多有用的資料。微軟的過時(shí)的JAVA SDK中也有類似的工具可供參考——一個(gè)用來
生成Jdirect（JDirect was the Microsoft's hack for implementing native interfaces）代碼的工具，利用它可以實(shí)
現(xiàn)訪問本地WIN32 API。SDK中有該工具的源代碼。順便提一句，由于這里涉及到微軟的一套獨(dú)特的JAVA擴(kuò)展標(biāo)記，因此SUN
和微軟一直就此問題打著官司。

Java compiler for CLI

它將JAVA源代碼（使用.NET 框架API）編譯為可執(zhí)行文件的格式，如EXE，DLL等，這個(gè)工作是在最高的層面上對JAVA
和.NET框架進(jìn)行整合。這將為今后直接利用JAVA在.NET框架下創(chuàng)建應(yīng)用打好基礎(chǔ)。

對現(xiàn)有JAVA編譯器的代碼生成部分重寫，將是此項(xiàng)工作一個(gè)比較便捷的解決方案。就我個(gè)人的意見，SUN會根據(jù)開放源代碼
的標(biāo)準(zhǔn)，開發(fā)這樣的一套編譯器。當(dāng)然，這樣的一些改造計(jì)劃需要對一些JAVA類進(jìn)行調(diào)整。

B組的項(xiàng)目

該組的項(xiàng)目將主要致力于為其他的平臺如PALM OS、SOLARIS以及LINUX平臺開發(fā).NET 框架的端口。這些端口應(yīng)該用C 來編
寫以適應(yīng)速度和控制上的需要，另外采用 C 來開發(fā)還可以保留進(jìn)行操作系統(tǒng)相關(guān)的系統(tǒng)級編程。

CLI ports for Palm OS, Linux and Solaris.

這部分內(nèi)容事實(shí)上分為兩個(gè)獨(dú)立的部分：一、針對PALM OS；二、針對UNIX 系統(tǒng)。

對于PALM OS 來說，解決方案比較簡單，開發(fā)可以在PC 環(huán)境下進(jìn)行，然后利用數(shù)據(jù)線或是藍(lán)牙傳輸?shù)絇ALM 設(shè)備上。與之
相關(guān)的.NET 框架針對PALM OS 設(shè)計(jì)的 API 將在下個(gè)部分詳述。

UNIX部分將利用JAVA開發(fā)，最后將PE（Portable Executeable）文件編譯為COFF（Common Object File Format）格
式，一種UNIX 可執(zhí)行文件的格式。編譯將在安裝或是載入時(shí)進(jìn)行。

.NET API and lib. bridge for Palm OS API.

這個(gè).NET API bridge 應(yīng)該以一種優(yōu)化的方式被映射到PALM OS API上。連接器和裝載設(shè)備的映射表駐留在PC 的網(wǎng)關(guān)上。
通過數(shù)據(jù)線或藍(lán)牙傳輸PALM OS 的可執(zhí)行代碼。它的實(shí)現(xiàn)將依賴于PALM OS 的駐留虛擬機(jī) KVM（the Java 2 Micro
edition）運(yùn)行時(shí)，同時(shí)它還應(yīng)該避免KVM設(shè)計(jì)中JAVA運(yùn)行程序載入過慢的缺陷。另外這一套API 與 為WINDWOS CE 的 設(shè)計(jì)
的不同，它不應(yīng)舍棄那些資源占用較大的API 象System.Xml。.NET依賴于SOAP進(jìn)行遠(yuǎn)程的方法調(diào)用。SOAP 基于 XML格式，
因此它需要System.Xml的支持。如果沒有，基于SOAP的分布式應(yīng)用將無法工作。通過調(diào)用System.Xml API 的方法可以實(shí)現(xiàn)
對PDA諸如WINDOWS CE 和 PALM OS上的應(yīng)用程序或是一些服務(wù)器端的應(yīng)用的遠(yuǎn)程操作。甚至可以在SOAP的基礎(chǔ)上利用為
WAP (Wireless Access Protocol)設(shè)計(jì)的WBXML (Wap Binary XML)標(biāo)準(zhǔn)與WAP 網(wǎng)關(guān)進(jìn)行通信。

.NET API and lib. bridge for POSIX.

這部分將對.NET API 和UNIX API進(jìn)行映射，大量的 C 的編程工作將是一個(gè)困難，但更大的困難將來自于GUI 元素的
處理上。這些UNIX平臺會有很多GUI框架，比較安全的做法是給它們提供一個(gè)WIN32 API 的端口作為媒介。如果能以前文所
述的MICROSOFT JAVA SDK的方法來進(jìn)行映射的操作，那么將節(jié)省大量的編程工作。

C組的項(xiàng)目

該部分的內(nèi)容致力于將.NET 框架應(yīng)用于JAVA上。這將是一項(xiàng)艱苦的工作。當(dāng)然，假如微軟向ECMA提交一份標(biāo)準(zhǔn)規(guī)范，這項(xiàng)
工作將變的比較實(shí)際一些。

CIL compiler to JVM

該項(xiàng)目將把.NET執(zhí)行程序（PE）轉(zhuǎn)換為.class格式的文件。但如果執(zhí)行程序中有一些非受管代碼，JVM將不接受它們。該項(xiàng)
目的實(shí)現(xiàn)依賴于下面將要描述的.NET API bridge for Java 的實(shí)現(xiàn)。

.NET API and lib. bridge for Java API.

一個(gè)完全兼容的.NET API bridge幾乎是不可能的，它需要依賴于微軟向ECMA提交的標(biāo)準(zhǔn)中的一些參數(shù)。這項(xiàng)工作將由JAVA
來實(shí)現(xiàn)，但與前文提到的Java API to .NET bridge一樣，將有很多煩瑣的工作。

C# compiler for JVM

這項(xiàng)工作可以用JAVA或是C# 的任意一種來完成。比較容易實(shí)現(xiàn)的是利用JAVA，因?yàn)橛蠸UN的JAVA編譯器的許多代碼可以
被再利用。但我建議用C# 來實(shí)現(xiàn)該項(xiàng)工作，在.NET 框架中有許多基礎(chǔ)的編譯器可被利用。此項(xiàng)目依賴于.NET API
bridge for Java的實(shí)現(xiàn)。

總結(jié)

最后我要說的是將.net 與JAVA 整合不僅僅是微軟與SUN的工作。所有的程序員也許都應(yīng)對它進(jìn)行關(guān)注。