自C#誕生之日起
關於C#與Java之間的論戰便此起彼伏
至今不辍
拋開Microsoft與Sun之間的恩怨與口角
客觀地從技術上講
C#與Java都是對傳統面向對象程序設計在組件化軟件時代的革新之果
可謂殊途同歸
雖說兩種語言有著
%的重疊
但那另外
%的較量
也往往能夠左右一架天平的方向
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#對組件編程的
迷戀
實際上現代軟件的組件開發潮流正是由
年誕生的Java所倡導
Java和C#都是對傳統C++面向組件的編程方式的革新
但
年前就出道的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 J
EE）
編程框架的支持
各種語言相關工具的實現
現有的系統基礎等都會對編程語言的發展產生相當的影響
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19571.html
