自C#诞生之日起，关于C#与Java之间的论战便此起彼伏，至今不辍。抛开Microsoft与Sun之间的恩怨与口角，客观地从技术上讲，C#与Java都是对传统面向对象程序设计在组件化软件时代的革新之果，可谓殊途同归。虽说两种语言有着“90%的重叠”，但那另外“10%的较量”也往往能够左右一架天平的方向。
C#和Java都提出了对传统C++艰深、晦涩的语法语义的改良。在语法方面，两者都摈弃了C++中函数及其参数的const修饰、宏代换、全局变量、全局函数等许多华而不实的地方；在继续方面，两者都采用了更易于理解和建构的单根继续和多接口实现的方式;在源代码组织方面，都提出了声明与实现于一体的更好的逻辑封装；在类型系统方面，两个语言都在中间语言IL或字节代码的基础上提出了映射这样的概念，彻底革新了传统C++运行时类型鉴别的问题。
但在大刀阔斧地对C++进行改革的同时，C#显得更为保守，它对很多原来C++中很好的特性予以了保留，如基于栈分配的轻量级结构类型、枚举类型、引用、输出、数组修饰的参数传递方式等，这些在Java中都被很可惜地丢掉了。在基本类型和单根继续的对象之间的类型统一方面，C#提出的box/unbox要比Java的包装类显得高明，效率也更高。
对C++不安全的指针及内存分配方式，C#和Java都采用了托管执行环境。而效率问题却是托管执行环境一直以来遭人诟病的地方。Java虚拟机（JVM）解释执行的方式曾经让很多开发者觉得“慢得无法忍受”,不过C#的JIT编译方式却为C#在这块战场上赢得了赞声一片，某些C#托管代码甚至比传统C++代码都快。虽然现在各厂商实现的Java平台也都一致地采取了JIT编译方式，但C#在这方面的比较优势非常明显——C#的目标编译语言IL从设计初始就把效率摆在了重要的地位，而Java字节代码的设计却有些鲁莽。
“一次编程，多处执行”一直是程序设计的一个诉求，尤其是在现代Internet时代。在跨平台方面，Java的支持和实现都是为人称道的，虽然JVM的速度仍然让人备感头疼。而C#虽然在底层构造方面对移植性进行了充分的考虑，但至少目前还没有出现成熟的、经过检验的产品。C#在跨平台方面似乎更热衷于XML Web Services互操作，而不是跨平台编程。但C#通过其基础语言构造（CLI）对二十多种主流语言对象级的互操作支持，又极大地提升了C#的技术地位。和COM组件廉价的互操作也为C#挣到不少分数——保持一个兼容的体系对现代软件工业非常重要，也是对广大开发人员负责的表现。
从对C#的分析中，我们可以强烈地感受到C#对组件编程的“迷恋”。实际上现代软件的组件开发潮流正是由1995年诞生的Java所倡导，Java和C#都是对传统C++面向组件的编程方式的革新，但7年前就出道的Java在这方面显然与C#不可同日而语。C#通过属性、索引器、委派、事件、操作符重载、特征、版本等实现了对组件编程的第一手支持。虽然这些在Java中都可以通过方法、接口或者适配器来间接地实现，但这无论对编程效率或者逻辑设计都是一种极大的损伤——高级语言首先面对的是人，而不是机器。
除去这些语言层面的组件支持机制，.NET平台也为组件的配置、运行和治理提供了一揽子解决方案，为组件开发量身定做的Visual Studio .NET更是令人兴奋，这些都为C#的组件编程开辟了广阔的天地。在其他技术方面Java的微弱劣势尚且可以忽略不计，但在组件编程方面Java相较于C#却有着不可治愈的硬伤。尤其对于从C++和VB背景过来的开发人员，C#在这方面有着不可反抗的魅力和诱惑。
鉴于XML Web Services在下一代企业分布式计算中的地位，.NET平台直接在IL中间语言中内置了XML，SOAP、UDDI、WSDL等底层协议被构建成了面向开发人员的组件；而Java是通过API集来支持Web服务。虽然这种局面的形成可能仅仅是因为时间问题，但从技术角度来将，C#无疑比Java更新，究竟C#出现在Java之后。
当然“语言选择乃艺术而非技术问题”，开发人员选择哪种编程语言往往会受到众多因素的影响。各自的后端平台（C# for .NET, Java for J2EE）、编程框架的支持、各种语言相关工具的实现、现有的系统基础等都会对编程语言的发展产生相当的影响。
