C#誕生之日起，關(guān)于C#與Java之間的論戰(zhàn)便此起彼伏，至今不輟。拋卻Microsoft與Sun之間的恩怨與口角，客觀地從技術(shù)上講，C#與Java都是對傳統(tǒng)面向?qū)ο蟪绦蛟O(shè)計(jì)在組件化軟件時(shí)代的革新之果，可謂殊途同歸。雖說兩個(gè)語言有著"90%的重疊"，但那另外"10%的較量"也往往能夠左右一個(gè)天平的方向。本文將攜90%之共，論10%之異，對兩個(gè)語言做純技術(shù)品評。文章不涉及兩個(gè)語言的公司，市場等臺面后的事情--雖然這往往也會影響人們對編程語言的選擇。也不預(yù)備得出誰是誰的Killer，讀者應(yīng)該選擇誰的問題。"語言選擇乃藝術(shù)而非技術(shù)問題"，業(yè)界早有定論，無需多言。
C#和Java都提出了對傳統(tǒng)C++艱深，晦澀的語法語義的現(xiàn)代改良。在語法方面，兩者都擯棄了C++中函數(shù)及其參數(shù)的const修飾，宏代換，全局變量和全局函數(shù)等許多華而不實(shí)的地方。在繼承方面，兩者都采用了更易于理解和建構(gòu)的單根繼承和多接口實(shí)現(xiàn)的方案。在源代碼組織方面，都提出了聲明與實(shí)現(xiàn)于一體的更好的邏輯封裝。在類型系統(tǒng)方面，兩個(gè)語言都在中間語言IL或字節(jié)代碼的基礎(chǔ)上提出了映射(Reflection)這樣的概念，徹底革新了傳統(tǒng)C++運(yùn)行時(shí)類型鑒別的問題。但在大刀闊斧地對C++進(jìn)行改革的同時(shí)，C#顯得更為保守，它對很多原來C++中很好的性質(zhì)予以了保留，如基于棧分配的輕量級的結(jié)構(gòu)類型，枚舉類型，引用（ref），輸出（out），數(shù)組（params）修飾的參數(shù)傳遞方式等，這些在Java中都被很可惜地丟掉了。在基本類型和單根繼承的對象之間的類型統(tǒng)一方面C#提出的box/unbox要比Java的包裝類顯得高明，效率也要好。
對C++不安全的指針及內(nèi)存分配方式，C#和Java都提出了托管執(zhí)行環(huán)境。效率問題是托管執(zhí)行環(huán)境一直以來令人詬病的地方，Java虛擬機(jī)（JVM）的解釋執(zhí)行方式曾經(jīng)讓很多開發(fā)者"慢的不可忍受"。C#的JIT編譯方式為C#在這塊戰(zhàn)場上贏得贊聲一片，某些C#托管代碼甚至比傳統(tǒng)C++代碼都快。雖然現(xiàn)在各廠商實(shí)現(xiàn)的Java平臺也都一致地采取了JIT編譯方式，但C#在這方面的比較優(yōu)勢非常明顯--C#的目標(biāo)編譯語言IL從設(shè)計(jì)初始就把效率擺在了重要的地位，而Java的字節(jié)代碼的設(shè)計(jì)卻有些魯莽。托管執(zhí)行環(huán)境經(jīng)過幾年的實(shí)踐，在現(xiàn)代軟件界已經(jīng)達(dá)成了共識，效率的犧牲換來的是高度安全的代碼--當(dāng)然前提是犧牲的效率必須足夠的小，至少可以忍受。值得指出的是在這里C#同樣"念念不忘老一輩C++程序員"，C#允許我們在unsafe上下文中進(jìn)行指針操作。數(shù)組的索引越界檢查，類型安全在C#和Java中都被提到了相當(dāng)?shù)母叨?。在異常處理方面，不管從?nèi)置支持，還是從執(zhí)行效率來講，C#都較Java略勝一籌。
"一次編程，多處執(zhí)行"是程序設(shè)計(jì)一直以來的一個(gè)訴求，尤其是在現(xiàn)代互聯(lián)網(wǎng)絡(luò)時(shí)代。在跨平臺方面，Java的支持和實(shí)現(xiàn)都是為人稱道的，雖然JVM的速度仍然讓人備感頭疼。而C#雖然在底層構(gòu)造方面對移植性進(jìn)行了充分的考慮，但至少目前還沒有成熟的，經(jīng)過檢驗(yàn)的產(chǎn)品。C#在跨平臺方面似乎更熱衷于XML Web Services互操作，而不是跨平臺編程。但C#通過其基礎(chǔ)語言構(gòu)造（CLI）對二十多種主流語言的對象級的互操作支持，又極大地提升了C#的技術(shù)地位。和COM組件廉價(jià)地互操作也為C#掙到不少分?jǐn)?shù)--保持一個(gè)兼容的體系對現(xiàn)代軟件工業(yè)非常重要，也是對廣大開發(fā)人員負(fù)責(zé)任的表現(xiàn)。
面向組件無疑是當(dāng)代軟件開發(fā)的主流。C#對組件編程甚至到了"迷戀"的地步，這與6年前就出道的Java不可同日而語--當(dāng)然這是時(shí)代問題。C#通過屬性，索引器，委派，事件，操作符重載，特征，版本等實(shí)現(xiàn)了其對組件編程的第一手的支持。雖然這些在Java中都可以通過方法，接口或者適配器來間接地實(shí)現(xiàn)，但軟件業(yè)的歷史告訴我們這無論對編程效率或者邏輯設(shè)計(jì)都是一種極大的損傷--高級語言首先面對的是人，而不是機(jī)器。除去這些語言層面的組件支持機(jī)制，.NET平臺也為組件的配置，運(yùn)行，管理等提供了一攬子解決方案，而為組件開發(fā)量身定做的Visual Studio.NET更是令人興奮，這都為C#的組件編程開辟了廣闊的天地。在其他技術(shù)方面Java的微弱劣勢尚且可以忽略不計(jì)，但在組件編程方面Java相較于C#卻有著不可治愈的硬傷。尤其對于從C++和Visual Basic背景過來的開發(fā)人員，C#在這方面有著不可抵擋的魅力和誘惑。
鑒于XML Web Services在下一代企業(yè)分布式計(jì)算中的地位，我們有必要在這方面對兩個(gè)語言有一個(gè)簡單的交代。在XML Web Services的操作方面，.NET平臺直接在IL中間語言中的內(nèi)置XML支持使得C#與生俱來地成為下一代Web服務(wù)的首選，這是通過API集來支持Web服務(wù)的Java所不能比的。在C#中，XML，SOAP，UDDI，WSDL等底層協(xié)議被構(gòu)建成了面向開發(fā)人員的組件，而Java中這些仍然是JAX(Java XML API)等底層協(xié)議的操作函數(shù)。當(dāng)然這種局面可能僅僅是時(shí)間問題，一個(gè)強(qiáng)大的高效的Web Services組件模型對Java來說并不是不可逾越的鴻溝。
在語言標(biāo)準(zhǔn)化方面，微軟也史無前例地做出了令人贊賞的動作。目前C#及.NET平臺基礎(chǔ)構(gòu)造已遞交歐洲計(jì)算機(jī)制造商協(xié)會ECMA，經(jīng)過標(biāo)準(zhǔn)化后的C#將可由任何廠商在任何平臺上實(shí)現(xiàn)其開發(fā)工具及其支持軟件，這為C#的發(fā)展提供了強(qiáng)大的驅(qū)動力。而Java在這方面雖有動作--JCP（Java Community Process），但無疑只能是準(zhǔn)標(biāo)準(zhǔn)化。在組件化軟件時(shí)代擁有一門像C++一樣的標(biāo)準(zhǔn)化語言，對軟件界尤其是廣大開發(fā)人員非常重要。
當(dāng)然兩個(gè)語言的全面的技術(shù)品評絕非僅僅上述幾點(diǎn)簡單的羅列比較，其后端平臺(C# for .NET, Java for J2EE)，及其編程框架的支持，各語言相關(guān)工具的實(shí)現(xiàn)，現(xiàn)有的系統(tǒng)基礎(chǔ)等等都對程序設(shè)計(jì)語言的發(fā)展產(chǎn)生相當(dāng)?shù)挠绊?。從純技術(shù)角度來講，C#無疑較Java更具競爭力。爭吵誰抄襲誰也沒有意義--技術(shù)的發(fā)展本來就是一個(gè)相互借鑒的過程。純技術(shù)較量也并不能決定這場論戰(zhàn)的勝負(fù)--如果非要一決雌雄的話。軟件界倒樂見競爭，經(jīng)過市場錘煉的技術(shù)才能更好地為我們服務(wù)，讓我們拭目以待!
聯(lián)系客服
