对于许多金融机构来说，当他们在几年内在这些平台上部署内部的或购买的解决方案时，这个J2EE-.Net问题可能仍不能解决。很显然，领先的公司，如J.P. Morgan Chase & Co., Bank One Corp., Wachovia Corp.和SunTrust Banks Inc.，以及许多其他大型的金融公司，将得出自己的结论，而微软公司，利用其.NET计划将在他们的企业信息技术战略中成为一个至关重要的合作伙伴。这些机构正在微软技术的基础上，允许一些最大容量的安全的Internet银行站点。
Sun Microsystems希望你认为，从其众多的J2EE开发商实施方案中选择其中一个方案将给你提供更广泛、更"开放的"选择。事实时，J2EE规范只是一个规范而已。因此，对于扩展，并且最终对于互用来说是开放的。
当你选择一家J2EE开发商时，开始使用其扩展的特性集(J2EE开发商利用它们在激烈的竞争中使自己与众不同)时，你就将自己锁定到了这个开发商。
Piper先生，做自己的事吧 - 我们必须开始进行优点之间的比较。适当的比较是将.NET Framework与某个具体的J2EE实施方案进行对比，而不是与价值极微的规范进行对比。当面对International Business Machines Corp.和BEA Systems Inc.一起占据J2EE市场的67%时，Java提供选择的想法显然是华而不实的。IBM公司最近发行了一个268页的文件，描述了将应用程序从非IBM WebSphere J2EE服务器转到WebSphere的步骤，从而进一步解释了"开发商中性"是一个神话。
在性能和可伸缩性的时代，当响应行业标准的服务器基准(如不同的TPC度量标准)时，提到IBM、Sun和Oracle公司都使用非Java的解决方案来吹捧他们的产品性能是值得的。
Piper先生说，Java和J2EE规范是为大型机规模的计算而设计的，而Sun公司自己的参照应用程序的.NET版本(一个假想的电子商务网站)处理的并发用户的数目为6.6到7.6倍。更糟的是，Enterprise Java Beans至今还没有提供重用或可伸缩性的承诺。一个Giga分析师最近说，一些对"J2EE围绕数据库访问的性能问题"灰心丧气的Java开发人员，至少在考虑如果J2EE的状况不能继续改进，是否可以在将来更认真地考虑新的.NET技术"。
Piper学生还反驳说，J2EE提供了更多的选择。尽管Sun公司可能会声称Java是一种标准，但Java仍然被Sun Microsystems控制。
Java还没有被提交给一家国际认可的标准团体，因此Java与其他广泛使用的语言，如Visual Basic相比，只不过是一个标准而已。
很不幸的是，任何在J2EE平台上进行程序设计的开发人员都已经有一种可以供选择的语言：Java。数百万的开发人员已经熟悉了Cobol、Basic、Perl、C++和Java语言，而.NET平台都支持这些语言。
Piper先生说，Java将允许银行在众多不同的操作系统上运行应用程序。银行是否愿意保留多种不同的操作系统，而尽力去维护众多不同渠道的客户关系呢？在这个场景中，Java将肯定会承诺"一次编写，到处调试(write once, debug everywhere)"。
底线是，Java和J2EE都以不同平台见之间的应用程序可移植性为目标。微软公司的.NET以使用工业标准的XML平台之间的应用程序集成为目标。这两种方法在哲学上是不同的。
我们相信，关键的客户需求是针对某个具体的平台进行了优化的高性能和可移植性，但还要准备与运行在不同平台上的应用程序进行集成。
我们感觉，.NET提供了一种非常简单、更加得体的开发模型，而与J2EE相比，使用.NET和Voyager平台的开发人员将不断地为电子金融提供更高性能的应用程序，而同时极大地降低他们的开发时间。
