.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就像是两兄弟，性格迥异，各有所长，只有在特定的环境下才会存在一种最优解，单纯讨论二者孰优孰劣，没有什么意义。当洞悉了语言背后的技术真想你就会发现，什么都是浮云，语言仅仅是工具而已。更高层次的解决方案设计、构架设计、项目控制等才是软件开发的真谛！