.NET與Java，因這兩種技術的相似性，總是會讓人拿來做比較，並且總有人想讓二者一分高下，最後得出孰優孰劣的結論。由於本人先用.NET，後轉Java，現在.NET與Java二者並用，所以對二者間的差異頗有體會，胸中之詞，不吐不快。
CLR VS JavaVM。虛擬機的概念讓Java/C#這些比C/C++更爲高級的語言成爲現實。Java虛擬機的確是劃時代之作，在功能、性能、跨平臺等各個方面都非常強大。後來微軟.NET中的CLR必然是借鑑了Java虛擬機的諸多優點，但CLR並未超越JavaVM，在跨平臺等方面還存在劣勢(mono還不夠實用)，但是應該說在Windows下，CLR已經足夠好用了。因此，在這一級別上二者應該是半斤八兩,.NET半斤，Java八兩。
C# VS Java。雖然C#推出要比Java晚很多，但是C#已經由模仿到發展，並實現了快速超越。.NET版本推陳出新，快速發展，而Java語言的發展則顯得疲軟無力。C#與Java都傳承了C++的語言風格，但C#在語言級別加入了更多新特性：屬性(property)、索引、委託等，這些新的語言特性讓人在用C#寫程序的時候感覺就像是在寫說明書一樣清晰簡單，而Java至今仍不肯加入這些特性，爲了實現相同的目的，Java程序員不得不使用一些開源包、一些編程約定、一些限制規則等拐彎抹角的實現簡單的功能。或許有人對此不以爲意，認爲只要由方法可以實現的特性就沒必要加入到語言中來。但是看一看.NET的每一次版本更新都會帶來更加簡潔的語法，更少的代碼即可實現更多的邏輯，這不就是編程語言不斷髮展的意義所在麼？在.NET2.0的時候，在Class裏面寫get/set屬性已經夠簡單了，但到了.NET3.0以後的版本，連get/set屬性的方法體以及私有變量都可以省略掉了，而在Java裏面，就不得不遵守約定的get/set方法的命名格式，不斷的檢查方法名稱是否正確，並編寫大量的代碼來維護這些get和set方法，即使這些代碼是由編輯器自動構造的，你也不得不面對這些枯燥的重複代碼以及代碼維護的問題。此外，Java還有一個讓人十分費解的設計。在C#中，一切類型都是類，使用int和使用Int32是完全一樣的，而在Java中，使用int和Integer則完全不同，int是一種值，而Integer則是一種類型，最要命的是在很多時候兩者之間不能自動轉換，即使是手動轉換也可能由於Integer類型等於null而導致轉換失敗，這個設計簡直就是C++中空指針問題的延續，這樣的設計問題比比皆是，雖然問題都很小，但使用起來十分不便，有時候都懷疑Java是否真的比C++更高級。時至今日，Java已經開始模仿C#了，Java語言後來的標註特性就是參考了.NET的屬性(Attribute)，而在Java7中即將到來的新特性在.NET中都能找到原型。Java語言已略顯老態，以JVM爲基礎的Scala和Groovy等新興語言大有替代Java的趨勢。
.NETFramework類庫VS開源Java庫。作爲主流的編程語言，肯定都離不開一整套類庫支持來實現基礎性的功能。不同的是.NET的類庫一般都由微軟提供，而Java的類庫一般都由開源項目提供。當我們需要某一.NET類庫時，常規的做法是查閱MSDN，查看微軟提供的代碼示例，然後模仿這些代碼即可；而當我們需要一個Java類庫時，一般的做法是到google或是開源社區搜索相關的開源項目，然後選擇所需要的類庫。至於兩種方式哪一個更好則很難說，但使用微軟的.NET類庫通常更簡單。雖然.NET也有開源類庫，但大多數.NET程序員都不會意識到還需要第三方類庫，微軟提供的類庫已經足夠了。當選擇開源類庫的時候，我們可以自豪的說，我們不用受制於微軟的技術壓迫，但是實際歷程可能是十分痛苦的。開源當然有其優點，但當爲了一個功能，而面對數個Java開源項目會怎麼樣？你可以慶幸你有ABCD多個選項，但選擇並不是件容易的事情。你不得不逐個的去學習研究每個開源類庫的設計結構、應用方法，逐個評估每個開源類庫的功能、性能，還有與需求之間的差距，除此之外，還要評估所選定的開源類庫是否能夠和其它類庫一起工作，是否存在潛在的衝突等等。當需要很多類庫、解決方案的時候，這種選擇足以讓人抓狂，這個時候你就會感嘆，要是沒有選擇該多好。除此之外還有另外一個差異：類庫風格與質量。由於微軟的企業化和工程化程度很高，海量的.NET類庫風格都能保持完全一致，讓人感覺所有的代碼都是一個人寫出來的；而開源項目都是由各個社區自發開展的，設計風格千差萬別，代碼質量也良莠不齊，Eclipse裏面有一個代碼重構的插件，當使用此功能進行代碼重構時，它甚至可以查找到配置文件中的類型引用並準確無誤的重構該引用，讓人驚歎是誰寫出來如此鬼斧神工的強大功能；而同時又發現在dom4j類庫中，一個很常用的方法竟然沒有對參數做非空檢查，導致四處拋出異常，真想把作者揪出來大罵一頓竟然會出現這麼低級的錯誤。當然大部分的開源項目都是很不錯的。凡事有利亦有弊，Java對程序員的折磨並非沒有回報，就像C++程序員要比Java程序員牛一樣，一般Java程序員在構架設計、模式設計以及對技術原理的理解上，都要比.NET程序員略勝一籌。微軟的溫室培育出來的大多數.NET程序員在面對苛刻複雜的問題時會顯得乏力，而對Java程序員來說，狂風驟雨只是家常便飯而已。
VisualStudio VS Eclipse。雖然記事本也可以編程，但我相信肯定沒有人會這麼做，編輯器對於開發的重要性就不做討論了。Eclipse並不是Java開發的唯一選擇，但Eclipse是頗具代表性的主流開發工具。VisualStudio 秉承了Windows家族的一貫風格：高度集成、簡單易用。Eclipse也秉承了開源家族的一貫風格：功能強大，無所不能，但操作卻不甚友好。VS的用戶很少會意識到還需要更多的插件更多的功能，也很少花太多時間去學習VS的使用方法；而Eclipse的用戶如果不會配置插件不會修改各種配置幾乎無法使用Eclipse，而且要花費不少時間來學習如何使用Eclipse，還是稍有難度的。但是說到功能，那就說到Eclipse的強項了，通過添加各種插件，Eclipse幾乎無所不能，甚至可以改造成C++、php、.NET的開發環境。Eclipse作爲Java的IDE在代碼編輯重構方面尤其優秀，在代碼調試時可以實現邊修改邊調試的代碼熱交換，在這些功能上，VS難以望其項背。Eclipse的大多數界面操作都是異步進行的，尤其是在編譯上，速度優勢十分明顯，而VS總會在編譯時出現假死，編譯速度很慢，當項目很多時讓人難以忍受。
行業應用與廠商支持。微軟有一整套完整的軟件生態系統，只要使用微軟的產品，那麼一切問題都由微軟包辦了。但微軟不是萬能的，微軟包辦的只能是一部分問題，在微軟不可企及的領域，就是IBM、HP、Oracle等各大軟件商的天下。由於微軟產品的定位，微軟的軟件生態體系比較接近於終端用戶，因此在行業應用上就更靠近中低端，而在大型應用項目中經常會見到Java的身影。因此在大型應用和軟硬件廠商支持上，Java的確比.NET更流行。目前如此，以後會如何發展尚未可知。
縱觀.NET與Java的技術體系，會發現二者有頗多相似，也有很多差異，最本質的差異應該是軟件開發思想上的差異，它們二者分別代表的是商業軟件體系與開源軟件體系，它們的差異也正是這兩大體系陣營的差異。商業軟件以服務客戶爲首要目標，在必要時寧可犧牲性能也要保證用戶的良好體驗；而開源軟件以解決問題爲首要目標，在任何時候，軟件的功能、性能、適應度都是最爲重要的，用戶的感受則其次。(客戶花錢買服務，當然有權吹毛求疵；用戶免費使用別人的服務，當然要心存感激。)
.NET與Java就像是兩兄弟，性格迥異，各有所長，只有在特定的環境下才會存在一種最優解，單純討論二者孰優孰劣，沒有什麼意義。當洞悉了語言背後的技術真想你就會發現，什麼都是浮雲，語言僅僅是工具而已。更高層次的解決方案設計、構架設計、項目控制等纔是軟件開發的真諦！