1．体系架构的比较 作为彼此竞争的应用平台，J2EE 和.NET 开发平台在目标和体系结构上极其相似，但在实现上又完全不同。 （１）类似的平台基础构造 J2EE 和.NET 两个平台在底层的执行引擎都源于托管的虚拟机概念,但.NET 的CLR 沿着Java 虚拟机(JVM)走得更远，CLR 在借鉴了JVM 的自动垃圾收集、异常处理等机制的同时，又为.NET 平台添加了多语言支持、组件自描述等新的特性。 在.NET 和 J2EE 平台上，程序的编译都经过两个类似的过程。首先，特定高级语言编译器将 C#（及其他.NET 语言）和Java 源代码分别翻译成中间语言(IL)和字节代码(ByteCode)。.NET 在中间语言设计时通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺；J2EE 的基石是 Java 语言，它最典型的特征是：一次编写，多次运行。跨平台是 J2EE 一直引以为豪的关键，这是通过 JVM 来实现的。 其次，在执行时，中间语言被即时编译器(JIT)编译成特定平台的二进制代码，字节代码则通过 JVM 解释执行，完成各自语言的指令功能。鉴于微软在“Wintel 平台”上的代码优化功底，.NET 代码的执行速度较之于Java 有明显的优势是不争的事实。但在Unix/Linux平台上，由于.NET 迟迟未能实现其跨平台的承诺，J2EE 几乎成了惟一的选择，执行效率的比较也就无所谓。在代码执行的同时，通用语言运行时和Java 虚拟机也都提出了异常捕捉、类型安全、内存分配和垃圾收集等自动化内存管理工作，大大减轻少了现代软件的内存泄漏问题，减轻了程序员的繁重负担。 面向对象程序设计在J2EE 和.NET 平台中都获得了直接的支持，单根继承加多接口实现是它们共有的特征。但在面向对象之外，.NET 对现代组件编程提供了直接支持。当然，当下很多企业中间件都是基于J2EE 平台，只是.NET 从设计、编码、配置到运行都给予了组件编程更多、更直接的支持。 在基础的和企业级的服务上两个平台很难一决高低。从基础的集合、字符串操作到企业级的API 接口，如 JMS、JDBC、JAX 和JNDI 等，J2EE 在这方面有着非常坚实的结构。微软.NET 框架类库也不示弱，提供了从图画、网络、线程到 ADO.NET、ADSI、Windows 表单和ASP.NET 等一系列的API。 除去 API 类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的。CLR 和Java 虚拟机都支持本地方法的调用。在异构平台方面，J2EE 更钟情于IIOP（Internet InterORB Protocol），而.NET 则使用SOAP。...
