.NET真的战胜了J2EE吗? |
作者:佚名 发布时间:2005-04-02 来源:不详
|
The Middleware Compa 10月发表的一篇有争议的报 Framework的The report co 到.NET 应用程序更快更容 的代码更少。) 这引起了Ja benchmarking)应该在更早 我只希望能够客观地对这两
|
ny (TMC)是一家从事Java培训和 告而引起了J2EE社团的争论。这 ntained benchmark tests似乎 易升级,能够用更少的时间来构 va社团的强烈抗议,尤其当一些 一些时候颁布时更是遭到了回击 种技术进行比较。
|
咨询的公司,由于该公司于2002年 篇有关J2EE和Microsoft .NET 在暗示.NET是优于J2EE的(比如提 建和配置,以及比J2EE 程序所用 分析家们指出该基准( 。我是不会参与到这些声讨中的,
|
该基准是TMC公司花费 TMC最初的计划是准备在这 Microsoft而未能和BEA、IB 来的结果显示Microsoft是
|
了巨大的努力才研究出来的成果 两个平台之间进行一场公平的测 M、Sun以及其他J2EE的成员取得 该项测试的投资者。
|
,然而其结果却并不那么理想。 试,但最终却因只联系到 联系而使得这一计划被迫中断。后
|
公众们还发现TMC邀请 调试,但却没有向J2EE方面 曾出版过两本备受好评的EJ 料的是,它并没有按照自己 eambean.com/petstore.htm
|
了Microsoft的专家来对用于该 寻求任何建议。也许TMC认为它 B书籍),就如它在其网站上声 所推荐的最佳实践来进行实施。 l中找到Rickard Oberg所做的分
|
基准的.NET Framework进行配置和 本身已经是J2EE领域的专家了(它 称的那样。很遗憾而且相当出乎意 (你可以在www.dr 析。)
|
先让我们将政治和金钱放到一边。.N J2EE?到目前为止这个答案还是未知的, 证的测试之后才能揭晓。然而,这里我想 ―我是说更认真地对待它。首先,我们来
|
ET Framework是否还能象去年年初发布时那样击败 要等到TMC重新指导一场包括Microsoft和J2EE权威认 指出为什么J2EE社团需要认真对待.NET的几点原因― 看看J2EE能够战胜Microsoft .NET的优势所在:
|
由于有着广泛的类库,Java的语言和 好几年才能赶上。
|
技术更成熟且经过大量测试,这一点Microsoft要花
|
Java是最早可用的商业
|
语言(它比Visual Basic .NET
|
还要更早一些)。
|
许多遍及世界的编译器和编程语言研 Java的社会知名度。比如,IBM曾采用Jik 选法(optimization)。而.NET还很新, 快便会有所改变。
|
究室都在使用Java,这些研究项目的结果直接提高了 es JVM及其编译器所完成的just-in-time(JIT)优 所以只有Microsoft在独自进行研究。但这种情况很
|
更多Java开放式资源项 container和JBoss,以及Jo 业的最佳选择。
|
目是用户无需花费太多成本便可 nas EJB服务器。这些产品通常
|
以得到的,比如Tomcat Web 证明Java是小型的、预算有限的企
|
然而,没有人能够低估 .NET比J2EE发展得更快:
|
Microsoft(去问问Sony有多担
|
心Xbox)。以下这些因素会证明
|
.NET运行于Windows平 。从事.NET的工程师能够访 容易的。在J2EE 同.NET之 的。然而,对于J2EE程序服
|
台,同其他产品相比,它是Micr 问到该操作系统的各个细节,因 间的任何角逐都要在Windows上 务器来说,Windows只不过是一
|
osoft产品中具有较高位置的一个 此对他们来说调试.NET程序是非常 进行,因为.NET还不是真正可移植 个黑盒子而已。
|
Microsoft已经证明了其在追赶新技 Framework的性能已经能够同更为成熟的J 现的新技术,比如缓存(caching)和服 可以实现缓存,因此极大地增强了性能。 Java开发人员不得不自己编写代码或者使 Taglibs project。而且,.NET早在去年 Java则会在未来的JavaServer Faces版本 事了。
|
术方面所取得的成功。仅仅用了一年时间,.NET 2EE相提并论了。.NET甚至还实现了许多J2EE未曾实 务器端组件。在ASP.NET 页面中,只需写一行代码便 相反,在Java规范中还没有任何关于缓存的定义。 用一个第三方工具来实现缓存,比如使用Jakarta 年初首次发布的时候就包含了GUI服务器端组件,而 中包含这些组件,但这会是晚于这一技术一年之后的
|
许多Java Web技术还没有形成标准, 荐使用的框架。它的使用非常普遍,但它 被普遍使用的技术不会被后来的一种新标 来说,这一点尤其会使人觉得困惑。而Mi
|
比如Struts,它是中等及大型Java Web应用程序所推 并未被当作一个标准来采用。所以谁也无法保证这种 准所取代。对于首次尝试选择一个服务器端技术的人 crosoft却不同,它支持所有Redmond出台的东西。
|
J2EE有着相当多的参与 BEA和IBM可以研究出导致产 会发展得更快。但这在商业 有时也会彼此竞争(包括JB Microsoft来统一管理,因
|
者。这就会鼓励产生更多的创新 生同样增强性能的相同的R&D, 竞争中并不一定能够实现。甚至 oss和Jonas,Tomcat和Jetty) 此也就没有什么冗余可言。
|
,而许多努力都是多余的。比如 如果他们参与竞争,那么他们一定 在开放式资源的社团中的成员之间 。另一方面,所有的.NET程序都由
|
新的Java规范是由许多 即使最小的参与者也能够提 Microsoft新技术则是由一 了其在实现新技术方面的速
|
合作企业和个人以一种假想的民 出自己的想法,但这样做通常是 些小组所起草的,他们能够更快 度是相当快的。
|
主形式共同起草的,当然这样使得 一个耗时的漫长过程。而 地做出决定。Microsoft已经证明
| |
|
|
|
|