下载文档原格式
J2EE与.NET技术架构的区别1.体系架构的比较作为彼此竞争的应用平台，J2EE和.NET开发平台在目标和体系结构上极其相似，但在实现上又完全不同。
(1)类似的平台基础构造 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从设计、编码、配置到运行都给予了组件编程更多、更直接的支持。
J2EE核心模式与.net架构在网络办公系统开发过程中的对比尚殿钧
【期刊名称】《吉林水利》
【年(卷),期】2008(000)0z1
【摘要】网络化平台的出现使"跨地域"、"无纸化办公"的梦想成为现实,而我院办公系统的顺利运行离不开先进的开发技术作为支撑,J2EE棱心模式与.net架构一直是OA编程开发中较为推崇的开发技术.本文通过对我院网络办公系统(OA)的开发和实现,介绍了J2EE核心模式与.net架构强大的功能与优势,对比各自的优缺点,从而在我院实现了"无纸化"、跨地域、高效率的办公需求.
【总页数】4页(P33-35,52)
【作者】尚殿钧
【作者单位】吉林省水利水电勘测设计研究院,吉林,长春,130021
【正文语种】中文
【中图分类】TP317.1
【相关文献】
1.J2EE核心模式与．net架构在网络办公系统开发过程中的对比 [J], 尚殿钧
2.基于J2EE架构的线损理论计算与诊断分析系统开发与应用 [J], 吴鸿亮;门锟;董楠;廖兵兵;郑全朝
3.J2EE架构在网上股票交易系统中的应用 [J], 向仕建;郭春梅;李也白
4.MVC模式在J2EE和.NET中的对比研究 [J], 杨慧
5.J2EE架构在网上股票交易系统中的应用 [J], 向仕建;郭春梅;李也白
因版权原因，仅展示原文概要，查看原文内容请购买。
J2EE与.NET的比较一、J2EE和.NET规范的比较对象模式应用服务器应支持分布对象模型，能将应用划分为多层，易于维护，在开发和部署过程中支持组件重用，模块化程度高，业务逻辑的变化只需修改相关的组件即可。
对象模式应用服务器遵循相应的标准和规范，其中较突出者主要有两大类：J2EE(Java 2 platform enterprise edition)类和微软.Net。
1、J2EE目前至少有40多种实现J2EE规范的应用服务器。
J2EE 为事务性Web应用的开发、部署、运行和管理提供一系列的规范和标准，主要包括Java Servlets，JSP(JSP(JavaServer Pages)是一种动态页面技术，它的主要目的是将表示逻辑从Servlet中分离出来。
)，EJB，JTA，JTS，JMS，JAXP，JMX， RMI-IIOP，JNDI，JCA，Java Mail和JAF规范。
这些J2EE规范为应用服务器的实现提供了一个完整的底层框架和一套标准的规范，在不同的J2EE应用服务器之上的应用组件也可以互操作，移植的风险和代价小。
而微软则在其操作系统上附加一系列具备中间件功能的软件包来提供应用服务器的相应的功能。
2、微软.Net构建在Windows DNA技术(如Microsoft Transaction Server， COM+， MSMQ， SQL Server数据库等)基础上，在.NET中提供了一系列企业级应用服务，为部署、管理和建立基于XML和Web 的应用构筑了.NET服务器结构，包括Application Center， BizTalkServer， Commerce Server， Exchange Server等，它们结合Windows 平台上的一系列开发工具和技术（包括Visual ， 等），提供了强有力的应用服务器解决方案。
结论：虽然目前J2EE和.NET势均力敌，但是J2EE作为一种规范，具有.Net无法比拟的跨平台、应用集成能力以及可扩展性和开放性，得到了许多厂商的支持，已逐步被广大研发人员和企业所接受，有良好的前景，逐渐成为Web应用服务器研究和开发的一个方向。
J2EE与.NET平台之间的差别你可以看到在J2EE与.NET平台技术之间由很大的重叠。
但是，如何在它们之间进行选择呢？在本节中，笔者将讨论我所看到的主要差别。
开发商中立性许多公司购买J2EE，他们相信这可以给他们开发商中立地位。
而实际上，这是Sun公司计划的一个确定目标：配置和实施各种满足J2EE规范需求的产品是可能的。
一个可移植的J2EE应用程序在这些产品[1]中的任何一个产品中被成功部署后，都可以正确地运行。
实际上，除了Sun J2EE的拥护者，很少有人相信这是可以实现的。
Paul Harmon是最重要的独立J2EE发言人之一，他是Cutter Consortium的首席顾问，广泛发行的Architecture/e-Business E-Mail Advisory的作者。
虽然Harmon总是反对J2EE，但他最近对J2EE的开发商可移植性写了这样不同寻常的坦诚的评价。
EJB模型是否已经达到了我可以将EJB组件从一个EJB应用服务器移动到另一个服务器的程度？在大多数情况下不能。
EJB规范不够全面。
通过提供专有的解决方案来完善这个模型，确保他们的客户可以创建生产系统，EJB应用服务器开发商弥补了这一点。
[2]Harmon总结了当今开发商中立的情况，他的评论如下：此刻，现实情况是如果你想开发一个EJB应用程序，你应当忠心于一个开发商。
[3]今天的现实是，没有像开发商中立这样的情况。
当然，.NET平台不是开发商中立的，它与微软公司的操作系统捆绑到了一起。
但是两者都不是J2EE的实现。
笔者可以给的最佳建议是，选择某一开发商，计划与其始终站在一起，这样可以充分利用该开发商所提供的平台优势。
整体成熟性第一个J2EE规范，EJB规范在1998年提出，而第一个β版本出现于1999年。
而这则是在与之相当的.NET平台技术，MTS，COM+的前身第一次实现的3年之后了。
笔者在最近的一篇文章[4]中讨论了从MTS到COM+的发展过程。
J2ee与.net（1）多系统整合和系统延展性跨平台的特性一直是J2EE 的最大特点，它通过Java 的虚拟机技术屏蔽了底层操作系统的细节。
从而实现了所编写的代码可以在Windows 平台上使用，也能够在Unix 平台上使用。
即所谓“一次编写，处处可用”。
在J2EE 规范里面又通过JDBC、JNDI 等技术屏蔽了诸如数据库、目录访问等网络细节。
可以这么说，目前用J2EE 技术实现的企业级应用可以运行在大机、Unix、windows、linux等各种操作系统上，后台可以连接Oracle、DB2、Informix 等等数据库，并且效率方面没有太多的区别。
在各系统连接方面，J2EE 也提出了很多很好的解决方案，例如J2CA——J2EE 联接器体系结构，就是J2EE 规范规定的如何使用Java。
技术与所谓遗留系统如ERP、CRM 等的连接方法。
当然J2EE 现在也提倡使用Web Service 等技术来进行系统互联。
总体而言，J2EE 技术是一套标准，它由诸多公司一起支持，所以技术的通用性和标准性比较高，目前基本上成为企业级解决方案的事实标准。
.Net 从本质上来讲不是一套标准，而是微软一系列产品的集合，所以，选择.Net 技术，基本上就选定了微软平台。
也就是说，操作系统只能使用Windows，甚至低层硬件只能选择Intel 的系列芯片。
而不能在大机、Unix 以及Linux 等系统上使用。
在数据库方面，.Net 在自身的Microsoft SQL Server 上也会比其他数据库运行得好。
在系统互联方面，.Net 提倡使用Web Service，这个技术目前还比较新，还没有太多的成熟可靠的解决方案。
总之，在多系统整合和系统延展性方面，基本上是J2EE 的特点，目前而言，.Net 技术还很难望其项背。
（2）I/O 处理和线程调度在这个方面，从应用的层面看，两者都能够达到企业级应用的需求。
但是I/O处理和线程调度从本质上来讲应该由底层硬件和操作系统来解决。
微软新一代系统构筑环境——.NET Framework是在研究Java的基础上开发出来的。
功能和架构也比较相似，由于它是在Java之后开发出来的，因此它有很多Java所没有的功能。
那么对.NET来说，是否存在不同于Java的、独特的应用领域和市场呢?。
由于Java已经先行积累了广泛的应用成果，积累了很多足以弥补其缺点的经验以及平台工具。
那么.NET Framework怎样与JAVA想抗很呢?我们先来看看.net的优势。
.NET的优势：企业信息系统部门可自行编程刚开始，微软就把易于开发XML Web服务作为.NET的优势而大加宣传。
以XML Web服务为前提而设计的.NET与Web服务具有极高的亲和性。
但XML Web 服务的产生却比较晚。
尽管业内对它的期待和关注程度较高，但由于可充分利用XML Web服务的“可赚钱的”业务模式尚未确立，所以目前与Web站点相比其市场仍微不足道。
.NET开发工具——Visual 的易用性使得它在Java很难实现的“用户企业(信息系统部门)也可编程的系统”上超人一头。
尽管.NET的标准语言和C#都与Java一样复杂，但是Visual 却很好地消除了这种复杂性。
此外，“成本比UNIX低”以及“可以充分利用Windows技术资源”等原因也在加速.NET Framework的普及。
作为客户端/服务器系统的开发环境，VB的后续语言——.NET中的“Windows Form”最具竞争力。
越来越多的系统集成商开始选择这一工具构筑系统。
但是.NET也有它的劣势，主要体现在大型系统中的应用成果少、缺乏“开放性”。
对于应用成果来说，今后其数量将会不断增加。
据悉，日本证券将在2003年度内利用.NET Framework全面重新构筑该公司目前利用ASP构筑的系统。
在“开放性”方面，由于可各种OS上运行，而且很多开发商还提供了Web应用服务器和开发工具，因此用户可以随意选择。
而开发商则通过在功能和性能方面相互竞争来不断提高产品水平。
J2EE与.NET这两种技术比较本文论述了J2EE与.NET这两种技术各自的优缺点，以及在不同的环境下，面对不同的客户要求，应采用哪种技术更合适。
一、引言JAVA技术和.NET技术是2003年以后逐渐流行的企业应用开发平台与技术，主要支持B/S结构的应用（注：B/S结构指系统软件安装时只需要在服务器端进行安装，后期维护也只需要在服务器端维护既可，普通用户使用时只需要用IE浏览器以浏览网页的方式浏览就可以，不需要在客户端做任何安装和操作，便于升级和维护）。
在一个历史时期，我相信每一种技术，每一个开发工具只要存在就有其存在的理由，它不可能一无是处，而是根据开发需要去选择一个最合适你的技术、产品。
开发技术和工具的比较没有绝对的标准。
评价一种开发工具，不仅要看它对设计模式、对象结构以及治理的支持情况，更重要的是要针对具体的使用环境、开发方法、结构体系、开发群体以及用户来评价一种工具的适宜程度。
软件技术的发展日新月异，基于各种技术的WEB应用更是琳琅满目，有关微软.NET与SUN公司(目前被Oracle收购)J2EE的“激战”也一直没有停止过。
二、J2EE与.NET的应用比较微软的东西是比较人性化的，有很多功能都从程序员的角度考虑方便了我们的编程。
比如说GridView等等。
而Java就不一样了，它主张的是“一次编译，到处使用”，有很多东西都要根据你的实际情况来配置，比起.NET要麻烦的多。
所以，要论开发速度，Java要逊于.NET。
为什么大家都感觉Java的东西比.NET安全呢？我想这是由于.NET出自微软，而且只能在window系列的操作系统上运行，window操作系统在桌面PC领域几乎是垄断地位，最轻易被关注和骚扰，所以其安全问题一直在困扰微软。
而Java由于是开源的，大公司、大企业、政府部门可以根据自己的需求来改写，非凡是安全机制的部分，这就需要一个合格的系统分析师、若干个技术优秀的核心程序员，也就使得J2EE产品价格不菲。
基于软件开发平台论J2EE和.NET随着信息技术的发展，软件开发平台已经成为了现代企业发展的重要组成部分。
在软件开发平台的选择上，J2EE和.NET是两种颇具代表性的选择。
本文将探讨基于软件开发平台的J2EE和.NET，比较两者的优缺点，为企业选择合适的开发平台提供参考。
1. J2EEJ2EE是Java平台企业版的缩写，是一种运行在服务器端的企业应用程序构建标准。
J2EE提供了一系列的API和服务，用于简化企业级应用程序的开发和集成，例如JSP、Servlet、EJB、JMS等。
J2EE具有跨平台、可移植性好、安全性高等特点，是企业开发web应用和企业级系统的常见选择。
优点：1）跨平台性。
Java语言具有跨平台的特性，J2EE应用程序可以在各种操作系统上运行，无需针对不同平台进行重新编译。
2）可移植性。
J2EE的应用程序可以轻松地在不同的服务器上部署，不会受限于特定的硬件或操作系统。
3）安全性高。
J2EE提供了强大的安全机制，包括认证、授权、加密等，保护企业应用程序的安全。
4）丰富的开发工具和框架。
J2EE拥有一系列成熟的开发工具和框架，如Eclipse、Spring、Hibernate等，提高了开发效率。
缺点：1）学习曲线较陡。
J2EE的学习成本相对较高，开发人员需要掌握复杂的API和规范。
2）部署和运维复杂。
J2EE应用程序的部署和运维相对复杂，需要熟悉各种服务器和容器的配置。
3）性能相对较低。
相比于其他技术栈，J2EE的性能相对较低，需要优化和调整。
2. .NET.NET是微软公司推出的一个面向Windows操作系统的应用程序开发框架。
.NET提供了一系列的工具和库，用于开发Windows应用、Web应用、移动应用等。
.NET拥有强大的集成性和稳定性，是企业开发Windows平台应用的常见选择。
优点：1）集成性强。
.NET可以无缝集成现有的Windows平台技术和服务，如Active Directory、Exchange等。
一、J2EE体系结构设计目前大多数企业采用J2EE技术的结构设计与解决方案。
对于我们学习和研究J2EE体系结构来说，了解与掌握J2EE体系结构的设计方法及一些常用模式是必须的；模型-视图-控制(model-view-control，简称MVC)结构是目前最常见的J2EE应用所基于的体系结构，MVC主要适用于交互式的Web应用，尤其是存在大量页面及多次客户访问及数据显示；相比较而言，一个工作流体系结构更多应用于过程控制和较少交互的情况下；除了体系结构外，J2EE的设计模式对我们解决应用系统的设计也有很大的帮助。
一、J2EE的模型-视图-控制（MVC）体系结构模型-视图-控制结构是交互式应用程序广泛使用的一种体系结构。
它有效地在存储和展示数据的对象中区分功能模块以降低它们之间的连接度，这种体系结构将传统的输入、处理和输入模型转化为图形显示的用户交互模型，或者换一种说法，是多层次的Web 商业应用；MVC体系结构具有三个层面：模型（Model）、视图(View)和控制(Controller)，每个层面有其各自的功能作用，MVC 体系结构如下：图1 MVC 体系结构模型层负责表达和访问商业数据，执行商业逻辑和操作。
也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。
视图层负责显示模型层的内容。
它从模型层取得数据并指定这些数据如何被显示出来。
在模型层变化的时候，它将自动更新。
另外视图层也会将用户的输入传送给控制器。
控制层负责定义应用程序的行为。
它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作；在一个图形界面中，常见的用户输入包括点击按钮和菜单选择。
在Web应用中，它包括对Web 层的HTTP GET和POST的请求；控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是不同的。
J2EE与.NET技术架构的比较随着三层/多层企业信息系统结构的深度发展和下一代分布式计算模型Web 服务的出现，软件开发中关于平台、框架、语言的竞争也愈演愈烈。
自从微软推出.NET平台，业界关于J2EE平台与.NET平台的比较从未停止过。
本文在收集整理相关文章的基础上，试图对目前两种主要的应用软件开发技术架构J2EE 与.NET进行一个客观、公正、全面的比较，以帮助软件开发商选择一个较为合适的开发平台进行应用软件的开发。
一、J2EE简介Java于1995年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet（小程序）。
后来，人们发现Java的“一次开发，多次运行”、纯面向对象的特性、垃圾回收机制和内置安全特别适合于开发企业应用系统。
于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。
但是各企业系统API之间又不能相互兼容，破坏了Java的平台独立性。
鉴于此，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1999年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。
这一规范和其定义的平台就构成了J2EE。
它定义了基于组件的方式设计、开发、组装和部署企业应用系统的各个组成部分。
同时，J2EE规范定义了分布式多层应用系统模型、组件重用策略、一体化的安全模型以及灵活的事务控制策略等，使得独立软件提供商（ISV）能够比以前更快的速度，向市场推出用户适应的解决方案。
J2EE是一套针对于企业级分布式应用的计算环境，其结构体系如图1所示。
它定义了动态Web页面功能（Servlet和Jsp）、商业组件（EJB）、异步消息传输机制（JMS）、名称和目录定位服务（JNDI）、数据库访问（JDBC）、与子系统的连接器（JCA）和安全服务等。
需要注意的是，J2EE本身是一个标准，而不是一个现成的产品（虽然现在有很多符合J2EE标准的产品），它由以下几个部分组成：（1）J2EE规范该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。
它是J2EE应用服务器开发商的大纲。
（2）J2EE兼容性测试站点 Sun公司提供的一个测试J2EE应用服务器是否符合J2EE规范的站点，对通过该站点测试的产品，Sun公司将发放兼容性证书。
（3）J2EE参考实现即J2EE SDK，它既是Sun公司自己对J2EE规范的一个非商业性实现，又是为开发基于J2EE企业级应用系统原型提供的一个免费的底层开发环境。
（4）J2EE实施指南即BluePrints文档，该文档通过实例来指导开发人员如何去开发一个基于J2EE的多层企业应用系统。
图1 J2EE体系结构图二、.NET简介.NET来自于微软，是一套全能的框架平台，支持C++、C#、J++、VB、ASP 等语言，能够解决C/S、B/S和单机等结构的软件开发需求。
.NET平台将这些语言编译成CLR语言，使它们可以无差别的运行在.NET Framework上，是2000年以后微软最为重要的软件开发套件产品。
.NET的绝大部分是微软Windows DNA(Distributed Network Architecture)的重写，DNA是微软以前开发企业应用程序的平台。
Windows DNA中包括了许多已经被证实的技术，新的.NET框架取代了这些技术，并包含了Web服务层和改良的语言支持。
图2是.NET开发平台的体系结构。
图2 .NET体系结构图.NET框架实现了语言开发、代码编译、组件配置、程序运行和对象交互等各个层面的功能，为Web服务及普通应用程序提供了一个托管、安全和高效的执行环境。
所有在.NET平台上创建的应用程序运行都需要两个核心模块:Common Language Runtime（CLR，通用语言运行时）和.NET Framework类库。
（１）CLR——.NET的虚拟机 CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。
它为.NET应用程序提供了一个托管的代码执行环境，托管意味着将原来由程序员或操作系统做的工作剥离出来交由CLR来完成，从而使程序运行获得更高的安全性和稳定性。
这些工作包括内存管理、即时编译、组件自描述、安全管理、代码验证以及其他一些系统服务。
CLR提供一个技术规范，无论程序使用什么语言编写，只要能编译成中间语言，就可以在它的支持下运行，这样.NET 应用程序就可以独立于语言。
CLR还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属性、事件、对象、继承性、多态性和接口等组件编程特性。
CLR中的自动垃圾收集器负责.NET应用程序运行时的内存分配、对象布局、内存释放等内存管理问题，彻底解决了多年来困扰程序员的内存泄漏问题，大大增强了应用程序的健壮性。
即时编译器在运行时，将中间语言以调用对象的方法将单位动态编译成本地二进制代码。
（2）类库 NET Framework类库向程序员提供软件组件，用来编写在CLR 控制下运行的代码，它们按照单一有序的分级组织提供了一个庞大的功能集，包括从文件系统到对XML功能的网访问的每一样功能。
该类库为开发提供了三种基本编程模板：基于的Web表单应用、基于的Web服务应用和基于传统GUI交互的Windows应用。
.NET Framework类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成，它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务，无论是传统的命令行程序，还是Windows图形界面程序，亦或是面向下一代互联网分布式计算平台的或Web服务应用，与在Windows和它的SDK中发送的代码库一样，.NET框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。
它将核心Win32 API最常用的功能和外挂SDK的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。
三、J2EE与.NET比较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框架类库也不示弱，提供了从图画、网络、线程到、ADSI、Windows表单和等一系列的API。
除去API类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的。
CLR和Java虚拟机都支持本地方法的调用。
在异构平台方面，J2EE更钟情于IIOP（Internet InterORB Protocol），而.NET则使用SOAP。
（2）相同的三层/多层体系基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。
在客户端，表示层负责用户与系统的交互。
对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：Java Application与Windows表单、Java Servlet/JSP与双双形成犄角之势。
但Windows表单依赖微软桌面系统的天然优势，无论在交互速度还是在界面的表现性能上都较Java Application稍胜一筹。
Servlet/JSP与是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。
虽然声称在底层通过编译执行获得了相当高的处理速度和服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高低。
在缓存、状态优化等方面两者可谓是旗鼓相当。
另一个与客户端应用相关的技术是ActiveX与Applet，从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。
在中间层，分布式业务组件负责企业应用的商业逻辑部署。
由于这些业务组件经常负责处理数据库连接、网络资源和线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。
J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。
.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，无需注册表和描述文件，对企业客户有一定的吸引力。
在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：J2EE的JDBC和.NET的，它们在支持传统SQL数据源的同时，也支持新型的XML数据源。
