在比較Java和C#的時候你不可能不注意到它們諸多的相似之處這在某種程度上要歸結於它們共同的來源C和C++但是當Gosling和他的同事們坐下來創造Java的時候他們不僅吸取了C++的能力而且更重要的是他們減掉了一些無用特性後者讓C++更容易出錯誤而且更難學習C#的設計者加入了很多C++的特性而Java也加入了這些特性但是C#卻沒有去掉C++的最糟糕的一些特性其結果就是這樣一門語言它仍然為所有人提供了所有的特性但其結局是內部沖突不斷而且過於復雜
散漫的句法缺陷
最容易找出的錯誤是流控制和句法C#提供了goto command將其作為更改程序執行點的機制自從Edsger W Dijkstra在年出版了他的《關於Go to陳述式害處的考慮（Go To Statement Considered Harmful）》Goto語句導致代碼難以調試而且很難被測試工具處理
在另一種不同的情況下操作符過載同樣也有很大問題只不過層次不一樣罷了當+根據操作數的類型而代表任何東西的時候代碼的功能就不再透明難以預料的副作用就會發生
C#在安全上的削弱
C#有一個用於將代碼區域標示為不安全的簡單機制在這些不安全的區域裡Java以及後來的C#安排到位了一些安全措施用以防止程序員直接修改內存位置以及使用點運算但是這些措施是值得懷疑的在使用具有垃圾清理功能的高級語言時如果下到內存地址這一層就會把對象/內存之間有意作出分離弄混錯誤就會容易出現調試成了惡夢緩沖區溢出再次抬頭C和C++裡著名的安全漏洞再次現身
C#還允許對主機系統上本機庫的簡單訪問這個與非NET對象相結合的訪問同Java本機接口（JNI）所提供的功能類似但是它更加危險JNI被設計用來小心地限制Java代碼以及本機代碼同已定義好的接口之間的交互操作NET使得調用本機對象文件變得極其簡單結果導致開發人員在做這的時候無法意識到他們在這一過程中把平台的可移植性也扔出了窗外
SOAP的集成
C#及其更大的擴展NET已經同SOAP Web服務緊密地集成在一起SOAP是使用XML指定參數和結果值來進行遠程過程調用的好標准但是它並不是唯一的方式利用用於Web服務的外部庫能夠允許Java開發人員輕易地更改其Web服務的風格使其成為SOAPXMLRPC或者什麼還沒有發明的東西當然C#的開發人員總是能夠選擇將外部庫用於SOAP的Web服務但是由SOAP標准的緊密集成所造成的限制要比它能夠做的東西更多
所有者的恐慌
C#裡最令人恐慌的特性可能就是其所有者了微軟已經為將C#和NET用於非Windows平台進行了精心的展示但是這在很大程度上還只是作秀其用於非Windows平台的CLR是問題多多錯誤多多它通過ECMA標准化過程來運行C#??這一步連Sun也不敢在Java上邁出
其擔心來自於微軟對此可能封鎖的程度如果它願意的話微軟已經申請了一個專利以排斥他人編寫第三方的CRL例如Mono計劃如果微軟決定對免費的C#和NET社區施壓它就有能力拿票子和法律的大棒把其開發活動趕回到Win平台??當然這也不是它想看到的情況
而Java語言則相反不是ECMA標准的真可惜Sun沒有遵從這一標准但是它是可以實現的而且沒有專利的阻礙其虛擬機和核心類庫都有來自第三方的開放和封閉源代碼的實現C#看起來是免費的其實不然而Java看起來限制很多但是它能夠依據法律通過免費的途徑來實現
最後我從來都沒有想到我會說這個但是Java具有更好工具的支持即使是在考慮到集成開發環境(IDE)的情況下Visual Studio NET是一個很不錯的IDE它代表了多年的努力而且特性很豐富但是Eclipse IDE包括了對Java的支持它在穩定性易用性和所提供的特性上超過了Visual StudioIBM對Eclipse的貢獻舉足輕重而且如果你信奉原來的軟件格言創建一個扔掉的(Build one to throw away)那麼你可以把Visual Age作為第一個(被拋棄掉了的)嘗試對於使用C#的開發人員來說幸運的是Eclipse的NET版本正在開發中
不是那麼差但是還不是Java
客觀一點評價C#裡並沒有什麼很恐怖的東西它沒有Visual Basic裡的那些很恐怖的東西而且它事實上也沒有繼承像C裡的一些東西而這些東西會讓開發人員開槍卻打中自己腳但是底線是C#並沒有做很多東西如果有任何東西比Java更好的話它在某些方面很明顯的要更差在這兩個非常類似的語言之間作選擇的時候請選擇稍稍更好且經歷風雨的那個Java
From:http://tw.wingwit.com/Article/program/net/201311/11937.html
