学步园

在语言方面，选择很简单。J2EE支持Java，并且只支持Java。在可预见的将来，它将不会支持其他任何种语言。.NET平台支持出Java以外的其他任何种语言（尽管它支持一种在语法和功能上与Java相当的语言，C#）。实际上，倘若.NET平台像一辆语言独立的车辆一样重要，在不远的将来，很可能任何一种出现的语言都支持.NET平台。

某些公司对J2EE支持其他语言所打动。尽管IBM公司的WebSphere和BEA公司的WebLogic支持其他语言，但是他们都不是通过J2EE技术实现的。在J2EE平台种，只有两种正式的方法来访问其他语言，一种是通过Java Native Interface，另一种方法是通过CORBA互用。Sun公司推荐采用后一种方法。正如Sun公司著名的科学家和Java设计师Rick Cattell在一次采访种所说：

你可以通过Java Native Interface功能和通过CORBA调用C++。CORBA可能是推荐的方法，因为它通过了更大的灵活性，并且我们已经设计了在认可的环境中能够很好地与CORBA一起工作的J2EE[1]。

在CORBA体系结构中创建任何新代码都是一个很有问题地策略。CORBA是20世纪90年代受人喜爱地体系结构，但现在已经不再使用了。据笔者所了解，没有一个CORBA开发商（除IONA外）在CORBA上盈利，并且没有一个开发商（包括IONA在内）在继续向该技术投资。底线是如果有人希望以Java以外的任何一种语言进行开发，那么J2EE是不正确的平台选择。

当前某些非Java公司正在考虑在Java上进行重新标准化的可能性。要实现这一点，有三种可能的方法：

再培训可能是最昂贵的选择。以我的经验，有很大的管理费用与将传统的程序员培训成精通面向对象的Java程序员有关。这是Gartner集团最近的研究的结果，得出得结论是将一个COBOL程序员培训成Java程序员，每人大约需花费6万美元[2]。 笔者相信，对于Visual Basic程序员，费用大体相当。并且在训练结束，你在生产力方面一无所得。你可以简单地雇佣一个现在可以编写与花费6万美元进行培训后编写的代码相同，但现在就可以使用Java编写该代码的程序员。在许多公司中，笔者曾经看到由于采用面向对象的技术损害生产力的情况，工作时间通常会浪费在了无休止的和没有成果的关于“正确的”面向对象的设计与分析的理论讨论上。

雇佣和/或替换职员同样代价昂贵。当前，Java程序员所要求的薪水比传统的Visual Basic/COBOL程序员高30%。在笔者的经验中，他们还有更高的新雇人员比率。

对于希望转向Java的公司来说，外包可能是唯一可行的选择。但是，假定外包可以完全使你摆脱上面提到的问题是不现实的，很显然，尤其是额外的程序员成本被转移给你的情况下，更是这样。

那么你应当使用什么语言呢？底线是，如果你有经过Java培训的职员， 并且已经有了合适的策略来确保对程序设计过程的有效管理，那么尽一切办法坚持下去。笔者个人喜欢使用Java作为程序设计语言，尽管笔者认为至少有其他好的语言。另一方面，如果你的店铺主要是由Visual Basic和COBOL组成，那么转向Java差不多肯定会是代价昂贵的、令人沮丧的一次体验。

你的语言选择并不会必定决定你在J2EE和.NET平台之间的选择。当然，如果你希望使用Java以外的某些东西，那么你就处于J2EE空间之外了。但是，Java的吸引力并不需要剥夺你使用.NET平台的权利 。.NET平台包括对C#（发音为C Sharp）支持，该语言是一种与Java很类似的语言，以至于许多人第一眼还不能将它们分辨开来。一个有经验的Java程序员可以在几小时内学会C#语法。

但是，如果你选择Java不是因为J2EE所声称的可移植性策略，那么C#或任何其他可以在.NET平台上运行的语言不大可能会让你愉快的。如果这样，很明显J2EE是你的选择。但是，在做出选择之前，一定要阅读有关可移植性的章节。.

J2EE的许多吸引力在于可移植性方面的承诺。有两种可移植性。的一种是开发商可移植性。笔者将这种可移植性称为开发商中立（vendor neutrality），前面已经讨论（并拒绝）了这种想法。第二种可移植性是操作系统可移植性（operating system portability）。这指的是在不对代码做任何改动的情况下，将代码基从一个操作系统转移到另一个操作系统的能力。与开发商中立不同，大多数J2EE实施最可能采取操作系统可移植性。

J2EE最可能会采取操作系统可移植性的原因是，在很大程度上并不是由于J2EE任何固有的可移植性，而是大多数J2EE开发商支持多种操作系统。因此，只要一个公司忠诚于一个既定的J2EE开发商和一个既定的数据库开发商，从一个操作系统转向另一个操作系统是可能的。这可能是唯一一个最重要的J2EE平台超过.NET平台的益处，而.NET平台仅限于Windows操作系统。但是，微软公司向ECMA（对JavaScript进行标准化的团体）提交C#规范和.NET Framework的一个子集（称为Common Language Infrastructure）毫无价值。

为什么开发商可移植性/中立令人满意很明显，但是操作系统可移植性有什么好处呢？我们认认为，一般有两种类型的公司需要操作系统可移植性：独立软件开发商（ISV，Independent Software Vendor）和寻求可收缩性解决方案的公司。

独立软件开发商（ISV）在有大量的非Windows平台客户群时需要操作系统可移植性。一个开发商不可能向依赖于.NET平台的Unix客户销售一件产品。如果.NET平台比J2EE好还是不好无关紧要。它并不在Unix上运行。

如果独立软件开发商的产品必须销售给非Windows客户，尤其是当J2EE平台本身需要与独立软件开发商的产品捆绑在一起作为集成产品提供时，J2EE提供了一个可接受的解决方案。

如果独立软件开发商的主要客户群是Windows客户，那么应当选择.NET平台。它可以在成本低得多的情况下提供好得多的产品。

许多需要操作系统可移植性的公司并不是独立软件开发商。这些公司的大多数公司认为可移植性是通向可收缩性的道路。这些公司相信他们，随着吞吐量需求的扩大，他们可以通过将应用程序移植到更高端硬件平台来获得更高的可收缩性。

如果你相信操作系统可收缩性能够以任何方式帮助你获得可收缩性，你正在犯一个严重错误。可收缩性不是一个硬件问题；它是一个软件问题。最高的可收缩性可以通过寻求高度可收缩的平台，然后尽可能地发挥该平台的优势获得。寻求在多个平台上运行的J2EE实施，在可获得的可收缩性方面还需很长的时间。到目前为止，在获得高可收缩性的能力方面，最好的被证明的平台是.NET平台。

使用笔者在关于可收缩性的一节中给出的数字，.NET平台可以从每分钟处理16,000笔交易增加到超过每分钟处理500,000笔交易。IBM WebSphere J2EE/Unix技术，是J2EE种类最好的代表之一，可能不会好于每分钟处理17,000到110,000笔交易，而每笔交易的成本则更高。

因此，可移植性并不是像看起来那么简单。如果你真的需要可收缩性，很明显，在.NET平台和J2EE中，.NET平台是胜者。如果你必须支持非Windows平台，那么很明显，J2EE是胜者。