C#和Java詳細描述
這里我們主要介紹C#和Java，包括介紹C#和Java都是對傳統C++面向組件的編程方式的革新，但7年前就出道的Java在這方面顯然與C#不可同日而語等方面。
自C#誕生之日起，關于C#和Java之間的論戰便此起彼伏，至今不輟。拋開Microsoft與Sun之間的恩怨與口角，客觀地從技術上講，C#和Java都是對傳統面向對象程序設計在組件化軟件時代的革新之果，可謂殊途同歸。雖說兩種語言有著“90%的重疊”，但那另外“10%的較量”也往往能夠左右一架天平的方向。
C#和Java都提出了對傳統C++艱深、晦澀的語法語義的改良。在語法方面，兩者都擯棄了C++中函數及其參數的const修飾、宏代換、全局變量、全局函數等許多華而不實的地方；在繼承方面，兩者都采用了更易于理解和建構的單根繼承和多接口實現的方式;在源代碼組織方面，都提出了聲明與實現于一體的更好的邏輯封裝；在類型系統方面，兩個語言都在中間語言IL或字節代碼的基礎上提出了映射這樣的概念，徹底革新了傳統C++運行時類型鑒別的問題。
但在大刀闊斧地對C++進行改革的同時，C#顯得更為保守，它對很多原來C++中很好的特性予以了保留，如基于棧分配的輕量級結構類型、枚舉類型、引用、輸出、數組修飾的參數傳遞方式等，這些在Java中都被很可惜地丟掉了。在基本類型和單根繼承的對象之間的類型統一方面，C#提出的box/unbox要比Java的包裝類顯得高明，效率也更高。
對C++不安全的指針及內存分配方式，C#和Java都采用了托管執行環境。而效率問題卻是托管執行環境一直以來遭人詬病的地方。Java虛擬機（JVM）解釋執行的方式曾經讓很多開發者覺得“慢得無法忍受”,不過C#的JIT編譯方式卻為C#在這塊戰場上贏得了贊聲一片，某些C#托管代碼甚至比傳統C++代碼都快。雖然現在各廠商實現的Java平臺也都一致地采取了JIT編譯方式，但C#在這方面的比較優勢非常明顯——C#的目標編譯語言IL從設計初始就把效率擺在了重要的地位，而Java字節代碼的設計卻有些魯莽。
“一次編程，多處執行”一直是程序設計的一個訴求，尤其是在現代Internet時代。在跨平臺方面，Java的支持和實現都是為人稱道的，雖然JVM的速度仍然讓人備感頭疼。而C#雖然在底層構造方面對移植性進行了充分的考慮，但至少目前還沒有出現成熟的、經過檢驗的產品。C#在跨平臺方面似乎更熱衷于XML Web Services互操作，而不是跨平臺編程。但C#通過其基礎語言構造（CLI）對二十多種主流語言對象級的互操作支持，又極大地提升了C#的技術地位。和COM組件廉價的互操作也為C#掙到不少分數——保持一個兼容的體系對現代軟件工業非常重要，也是對廣大開發人員負責的表現。
從對C#的分析中，我們可以強烈地感受到C#對組件編程的“迷戀”。實際上現代軟件的組件開發潮流正是由1995年誕生的Java所倡導，C#和Java都是對傳統C++面向組件的編程方式的革新，但7年前就出道的Java在這方面顯然與C#不可同日而語。C#通過屬性、索引器、委派、事件、操作符重載、特征、版本等實現了對組件編程的第一手支持。雖然這些在Java中都可以通過方法、接口或者適配器來間接地實現，但這無論對編程效率或者邏輯設計都是一種極大的損傷——高級語言首先面對的是人，而不是機器。
除去這些語言層面的組件支持機制，.NET平臺也為組件的配置、運行和管理提供了一攬子解決方案，為組件開發量身定做的Visual Studio .NET更是令人興奮，這些都為C#的組件編程開辟了廣闊的天地。在其他技術方面Java的微弱劣勢尚且可以忽略不計，但在組件編程方面Java相較于 C#卻有著不可治愈的硬傷。尤其對于從C++和VB背景過來的開發人員，C#在這方面有著不可抵擋的魅力和誘惑。
鑒于XML Web Services在下一代企業分布式計算中的地位，.NET平臺直接在IL中間語言中內置了XML，SOAP、UDDI、WSDL等底層協議被構建成了面向開發人員的組件；而Java是通過API集來支持Web服務。雖然這種局面的形成可能僅僅是因為時間問題，但從技術角度來將，C#無疑比Java更新，畢竟C#出現在Java之后。
當然“語言選擇乃藝術而非技術問題”，開發人員選擇哪種編程語言往往會受到眾多因素的影響。各自的后端平臺（C# for .NET, Java for J2EE）、編程框架的支持、各種語言相關工具的實現、現有的系統基礎等都會對編程語言的發展產生相當的影響。 以上介紹C#和Java詳細描述。
【編輯推薦】
