C#和Java都是很不错的语言。他们通过类似的方式达到了类似的目的，尽管C#比Java多出来一些和句法相关的东西，例如foreach关键字和一些更加让人高兴的扩展／实现架构。不幸的是，这些改进的光芒被削弱的东西掩盖掉了。在本文里，我将比较两种语言，并尽量避免深入到JVM和CLR层。
Java：无可争辩地具有C++所有的精华
在比较Java和C#的时候，你不可能不注意到它们诸多的相似之处，这在某种程度上要归结于它们共同的来源：C和C++。但是，当Gosling和他的同事们坐下来创造Java的时候，他们不仅吸取了C++的能力，而且更重要的是，他们减掉了一些无用特性，后者让C++更容易出错误而且更难学习。C#的设计者加入了很多C++的特性，而Java也加入了这些特性，但是C#却没有去掉C++的最糟糕的一些特性。其结果就是这样一门语言，它仍然为所有人提供了所有的特性，但其结局是内部冲突不断，而且过于复杂。
散漫的句法缺陷
最容易找出的错误是流控制和句法。C#提供了goto command，将其作为更改程序执行点的机制。自从Edsger W. Dijkstra在1968年出版了他的《关于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服务的风格，使其成为SOAP、XML-RPC，或者什么还没有发明的东西。当然，C#的开发人员总是能够选择将外部库用于SOAP的Web服务，但是由SOAP标准的紧密集成所造成的限制要比它能够做的东西更多。