在语言方面，选择很简单。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是你的选择。但是，在做出选择之前，一定要阅读有关可移植性的章节。
