首先是對JAVA 和 .NET平臺的構成做一個分析，然后是我個人對JAVA如何形成的一個認識，接著是分析微軟和SUN
之間的合作與分歧，最后是JAVA與.NET合作的前景。
我個人強烈認為JAVA與.NET將在不久的未來逐步的統一起來。已經有很多關于整合JAVA和.NET的項目計劃被提交到源碼開
放組織。在微軟的MSDN，SUN 的JAVA站點，以及來自于ECMA 和 W3C.org的標準文檔都可以看到有關內容。
簡介JAVA與.NET繼續發展下去，可能的兩種結果：其中的一種退出競爭或是兩種共存，而共存的可能性更大。JAVA得以生
存的原因在于它的時間優勢：它已經發展了六年；它在大多數的操作系統上可以運行；它得到了業界領導者如ORACLE、IBM
的支持；并且使用JAVA進行開發的項目計劃幾乎覆蓋所有的應用程序領域。
而.NET的優勢在于微軟擁有90%的桌面操作系統市場，同時微軟也開始采用SUN的市場戰略，即將其特有的技術標準
化。如：在遠程通信上它向IETF（InternetEngineering Task Force）和W3C（World Wide Web Consortium）提交了SOAP
（SIMPLE OBJECT ACCESS PROTOCLE）（類似于RFC-REQUEST FORCOMMENT）；向ECMA (European Computer
Manufacturer's Association)提交了C#語言和通用運行時（COMMON RUNTIME）基礎結構的標準。
JAVA平臺的構架JAVA平臺包括JAVA語言，以及一套虛擬機——如JVM、KVM、CVM等——通過它們實現在PC機，手提電腦或是嵌入式系
統上運行JAVA的字節碼。同時，JAVA平臺還定義了一整套覆蓋面很廣的API，它們被用來與微軟的API協調或是相互競爭。
如JDBC對ODBC，JTAPI對TAPI，JDO對ADO等等。因此，簡要來說，JAVA平臺包括語言，虛擬機，以及API庫。
由于使用虛擬機機制，所以JAVA語言在所有的平臺上只有唯一的版本，因此它使用RMI（遠程方法調用Remote
Method Invocation）協議進行遠程通信；微軟則在.NET框架中使用DCOM——正在逐步演變為SOAP（簡單對象訪問協議）。
SUN最初對JAVA的宣傳是“一次性代碼編寫，所有環境下運行”，但在推出了“J2EE” (Java 2 Enterprise
Edition)和“J2ME” (Java 2 Micro Edition)后不得不收回了它最初的宣傳，因為“一種尺碼的鞋適合所有的腳”的解決
方案并不能很好的工作。
.NET平臺的構架
.NET框架包括C++, VB.NET (VB 7.x) 和 C# 等一系列語言；與JAVA虛擬機類似的一套運行時環境；以及一套傾向與
WINDOWS體系的API接口。其中的運行時環境可能存在于一個瀏覽器、或是一個WEB SERVER、或是在操作系統中。將來也許
在SQL SERVER中也可能存在這樣的運行時環境。另外需要提及的是微軟的SOAP協議，它在繼承了DCOM的一些特性的基礎上
發展起來，基于XML格式通過HTTP進行傳輸。SOAP的JAVA版本，可以在http://xml.apache.org上看到它的有關文檔。
發展歷程
JAVA最初來源于SUN的一套為機頂盒設計的語言，當時的名字是OAK，SUN將之更名，并將它放在INTERNET上作為開放源碼共
享。隨著專門為網頁設計的JAVA APPLET的出現，JAVA語言迅速在INTERNET上流行起來。當時的瀏覽器主要是NETSCAPE。當
微軟發現明天市場的主宰可能是瀏覽器而不是桌面系統時，開始著手對NETSCAPE進行收購，在收購計劃失敗后微軟發展了
自己的瀏覽器IE。
當時的INTERNET需要一種語言，而JAVA適時的出現了，由于它與C++的許多相似的語法，使得很多程序員轉向了JAVA。而它
確實具有很多優勢，以至于在98年秋，它的反對者微軟在MSDN中都宣稱，JAVA是編寫COM組件的最佳語言。
隨著JAVA一起出現的還有LINUX操作系統和APACHE服務器。這三者的聯合在服務器端的應用表現出強大的威力，以至
WINDOWS NT在企業級服務器市場受到了很大的沖擊。
98年出現的DHTML和JAVASCRIPT導致了JAVA APPLET在網頁設計領域的淡出，在這里有兩方面因素：一、大部分APPLET效果
現在都可以由DHTML完成；二、而DHTML對帶寬的要求更低。但是JAVA因為在服務器端的應用仍有市場，而得以繼續發展。
這是開發源碼的支持者為JAVA添加了活力，首先是APACHE提出的SERVERLET 和 稍后出現的JSP，這些在.com網站的程序開
發中占據了一席之地。
JAVA平臺首先以SERVERLET，然后是JSP，最后是EJB(Enterprise Java Beans)，逐步向企業級應用拓展。EJB是一個面向對
象的事務進程系統，有些類似于微軟的MTS（Microsoft Transaction Server）。事實上MTS和EJB都不是很成功，因為它們
都無法達到INTERNET應用的規模。
就我的觀點來看，JAVA最失敗的時刻是，SUN通過法律手段向微軟索賠$2000萬，并獲得成功的時候。微軟從那時開始
制訂自己的.NET計劃，同時也宣布了JAVA作為獨一無二的INTERNET 平臺的地位的結束。
展望
現在，我們能看到到還只是一個很混亂的局面。而在未來，我們將看到.NET的成熟，以及它和JAVA的融合。
JAVA將繼續保持它的特點：跨平臺的服務器端應用，如WAP服務器，或者是電信領域的如JAIN(Java API for Intelligent
Networks，同時它在嵌入式系統中將繼續保持它的優勢，象智能卡、移動電話、PDA等。而我們還將看到.NET的成熟，當然
這種成熟需要時間，可能是相當長的一段時間，就好象當年JAVA成長那樣。
ORACLE 8i 及其更老一些的版本，充當著一個JAVA 運行時的載體的角色，這使得JAVA 得以與ORACLE 數據庫引擎緊密結
合；同樣，.NET體系也會與新版本的SQL SERVER，緊密的結合，這將包括一個VES （虛擬執行系統）執行引擎。這將使程
序開發人員可以在SQL 語句和存儲過程中嵌入C#和VB.NET 的成分。目前，你可以通過調用DLL函數來使用擴展存儲過程，
但數據庫本身并沒有一個面向對象的運行時引擎與之相匹配。
未來的標志.NET 成熟的里程碑
非微軟產品，包括服務器，桌面或是便攜式設備的操作系統如Solaris, Linux和Palm OS的.NET接口。與JAVA核心的整合。
比如說，針對CLI（Common Language Infrastructure）的JAVA編譯器，針對JAVA虛擬機的C#編譯器。SQL SERVER 或是
ORACLE 等數據庫產品中整合的VES 引擎。由中立的第三方開發的開放源碼的，完善的.NET平臺。
可以預見到，微軟將會贊助一些開放源碼的項目，以使.NET 向UNIX 平臺擴展，而這將有助于一些開放源碼組織減少它們
對JAVA的偏愛。
JAVA的命運
JAVA的一個主要目標是通信設備提供商，如NOKIA就在它的WAP SERVER 應用了JAVA。類似于70年代和80年代初，PC銷
售時硬件供應商將最終的應用程序綁定在操作系統中一起銷售，JAVA現在也被綁定于通信設備中被銷售。
它的另一個主要方向是JAIN（Java API for Advanced Intelligent Network），它主要是定義一套與協議（如CDMA，
GSM，IMT2000）無關的API，以便于基于開放市場的組件開發。這使得ISV（獨立軟件供應商）可以以插件的形式提供通信
服務，如可自動轉接至最近的可撥通的國際呼叫中心的800免費電話。當然，JAIN也遇到了對手，想微軟和不列顛通信提出
的Parlay計劃——它也被業界所支持。
另外，JAVA在嵌入式設備中也保持著領先的地位，如smart 3G 和 GPRS，在這里的移動電話系統采用的是J2ME（Java 2
Micro Edition），但是如果它不能很好的解決一些固有的問題，如載入時的延遲等，也許，很快，它就將被C#代替，如
果.NET 能提供快速的運行環境，和廣泛的業界支持。
.NET和JAVA的整合
無論從商業角度，還是開發者角度，甚至是源碼開放組織的角度，.NET和JAVA的整合都顯得很有必要，下面就二者的整合
做出一個提前的估計（所有的相關項目被分為A、B、C三個組，以便于看清它們之間的關系，當然這些項目也完全可以被獨
立的操作）：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組的項目
該組項目的主要目的是使現有的JAVA二進制代碼能夠在.NET平臺上被執行。這意味著JAVA的二進制碼（后綴為class
的文件）不用再從源代碼進行重編譯就能運行于.NET 平臺了。當然這些class 文件在安裝或執行時會被編譯，就好象微軟
的運行時和JIT對微軟中間語言所做的那樣。JVM to CIL compiler一個編譯器，輸入JAVA字節碼，輸出MSIL代碼——它將被編譯為可執行文件（如EXE，DLL，MSI等）
Java API bridge for .NET API and lib
在這里，JAVA API 與每一個相應 .NET API之間將建立一個映射，比如Java API中的java.io.File將被映射到 .NET的
System.IO.File 類。相對于比較簡單的IO類的映射，還有一些映射比較復雜，比如java.net包到.NET 的SYSTEM.NET的映
射。這里存在的一個問題是：該項工作如果在C#中進行開發會比較方便。而假如在JAVA中實現，則需要有一個直接指向CLI
（Common Language Interface）的編譯器，它能生成符合CLS（Common Language Specification）標準的CIL（Common
Intermediate Language）代碼。
可以通過編寫一個向導式的工具來避免一些煩瑣的工作，例如，可以利用C# 或JAVA來編寫一個基于XML格式的對象描述，
用它生成一個框架代碼，然后根據需要向其中手寫添加其他代碼。如果你確實打算進行這樣的操作，在
http://xml.apache.org站點你可以找到很多有用的資料。微軟的過時的JAVA SDK中也有類似的工具可供參考——一個用來
生成Jdirect（JDirect was the Microsoft's hack for implementing native interfaces）代碼的工具，利用它可以實
現訪問本地WIN32 API。SDK中有該工具的源代碼。順便提一句，由于這里涉及到微軟的一套獨特的JAVA擴展標記，因此SUN
和微軟一直就此問題打著官司。
Java compiler for CLI它將JAVA源代碼（使用.NET 框架API）編譯為可執行文件的格式，如EXE，DLL等，這個工作是在最高的層面上對JAVA
和.NET框架進行整合。這將為今后直接利用JAVA在.NET框架下創建應用打好基礎。
對現有JAVA編譯器的代碼生成部分重寫，將是此項工作一個比較便捷的解決方案。就我個人的意見，SUN會根據開放源代碼
的標準，開發這樣的一套編譯器。當然，這樣的一些改造計劃需要對一些JAVA類進行調整。
B組的項目該組的項目將主要致力于為其他的平臺如PALM OS、SOLARIS以及LINUX平臺開發.NET 框架的端口。這些端口應該用C 來編
寫以適應速度和控制上的需要，另外采用 C 來開發還可以保留進行操作系統相關的系統級編程。
CLI ports for Palm OS, Linux and Solaris.這部分內容事實上分為兩個獨立的部分：一、針對PALM OS；二、針對UNIX 系統。
對于PALM OS 來說，解決方案比較簡單，開發可以在PC 環境下進行，然后利用數據線或是藍牙傳輸到PALM 設備上。與之
相關的.NET 框架針對PALM OS 設計的 API 將在下個部分詳述。UNIX部分將利用JAVA開發，最后將PE（Portable Executeable）文件編譯為COFF（Common Object File Format）格
式，一種UNIX 可執行文件的格式。編譯將在安裝或是載入時進行。
.NET API and lib. bridge for Palm OS API.這個.NET API bridge 應該以一種優化的方式被映射到PALM OS API上。連接器和裝載設備的映射表駐留在PC 的網關上。
通過數據線或藍牙傳輸PALM OS 的可執行代碼。它的實現將依賴于PALM OS 的駐留虛擬機 KVM（the Java 2 Micro
edition）運行時，同時它還應該避免KVM設計中JAVA運行程序載入過慢的缺陷。另外這一套API 與 為WINDWOS CE 的 設計
的不同，它不應舍棄那些資源占用較大的API 象System.Xml。.NET依賴于SOAP進行遠程的方法調用。SOAP 基于 XML格式，
因此它需要System.Xml的支持。如果沒有，基于SOAP的分布式應用將無法工作。通過調用System.Xml API 的方法可以實現
對PDA諸如WINDOWS CE 和 PALM OS上的應用程序或是一些服務器端的應用的遠程操作。甚至可以在SOAP的基礎上利用為
WAP (Wireless Access Protocol)設計的WBXML (Wap Binary XML)標準與WAP 網關進行通信。
.NET API and lib. bridge for POSIX.這部分將對.NET API 和UNIX API進行映射，大量的 C 的編程工作將是一個困難，但更大的困難將來自于GUI 元素的
處理上。這些UNIX平臺會有很多GUI框架，比較安全的做法是給它們提供一個WIN32 API 的端口作為媒介。如果能以前文所
述的MICROSOFT JAVA SDK的方法來進行映射的操作，那么將節省大量的編程工作。
C組的項目
該部分的內容致力于將.NET 框架應用于JAVA上。這將是一項艱苦的工作。當然，假如微軟向ECMA提交一份標準規范，這項
工作將變的比較實際一些。
CIL compiler to JVM該項目將把.NET執行程序（PE）轉換為.class格式的文件。但如果執行程序中有一些非受管代碼，JVM將不接受它們。該項
目的實現依賴于下面將要描述的.NET API bridge for Java 的實現。
.NET API and lib. bridge for Java API.
一個完全兼容的.NET API bridge幾乎是不可能的，它需要依賴于微軟向ECMA提交的標準中的一些參數。這項工作將由JAVA
來實現，但與前文提到的Java API to .NET bridge一樣，將有很多煩瑣的工作。
C# compiler for JVM這項工作可以用JAVA或是C# 的任意一種來完成。比較容易實現的是利用JAVA，因為有SUN的JAVA編譯器的許多代碼可以
被再利用。但我建議用C# 來實現該項工作，在.NET 框架中有許多基礎的編譯器可被利用。此項目依賴于.NET API
bridge for Java的實現。
總結最后我要說的是將.net 與JAVA 整合不僅僅是微軟與SUN的工作。所有的程序員也許都應對它進行關注。